Improving performance on Raspberry Pi about dab-cmdline HOT 6 CLOSED

I've been running example-3 on my desktop which has a powerful processor and it works without hiccups. Now I switched to running it on a raspberry pi 3 revision B, it runs semi-smoothly but I do get reports from aplay that the buffer is underrun. Looking into improving this, I've tried multiple things: - Add define for __THREADED_DECODING, when looking in the code I do not understand how this is supposed to do anything, this define is not used in any part of the code? It also seems to have no noticeable effect: only 1 core of the Pi is going to 100% and the other ones are doing seemingly nothing. - Use example-4 and then mplayer to play the AAC frames, as to take the decoding load of the dab-cmdline. When running this example, nothing gets written to stdout. - When looking into the qt-dab repo, you mention something about a latency option, is this option possible to use in this repo and will it improve performance? Thanks in advance for the help. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#45>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AITzwLk9rnK848g5us_iTsxYFWeOhJipks5uNs1FgaJpZM4VvVAX> .

OK tomorrow I'll have access to my RPI3 and run some tests. afaik the __THREADED_DECODING is not relevant in the cmdline code, there are at least three threads running a. the ofdm handling b. the msc decoding c. the audio decoding The library code is made threaded by default. as said I'll have a look (and check) tomorrow best jan 2018-08-05 12:47 GMT+02:00 Bart Peeters ***@***.***>: > I've been running example-3 on my desktop which has a powerful processor > and it works without hiccups. > > Now I switched to running it on a raspberry pi 3 revision B, it runs > semi-smoothly but I do get reports from aplay that the buffer is underrun. > Looking into improving this, I've tried multiple things: > > - Add define for __THREADED_DECODING, when looking in the code I do > not understand how this is supposed to do anything, this define is not used > in any part of the code? It also seems to have no noticeable effect: only 1 > core of the Pi is going to 100% and the other ones are doing seemingly > nothing. > - Use example-4 and then mplayer to play the AAC frames, as to take > the decoding load of the dab-cmdline. When running this example, nothing > gets written to stdout. > - When looking into the qt-dab repo, you mention something about a > latency option, is this option possible to use in this repo and will it > improve performance? > > Thanks in advance for the help. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#45>, or mute the > thread > <https://github.com/notifications/unsubscribe-auth/AITzwLk9rnK848g5us_iTsxYFWeOhJipks5uNs1FgaJpZM4VvVAX> > . > -- Jan van Katwijk +31 (0)15 3698980 +31 (0) 628260355

Hi Jan, I was running example-3 in the form of: ./dab-rtlsdr-3 -C 12A -P 'Studio Brussel' -W 20 -Q | aplay -r 48000 -f S16_LE -t raw -c 2 -D default:CARD=Amanero, which made aplay report buffer underruns. I now tried running example-2 and everything works really good now, no interruptions and all of the cores seemed to be used: %Cpu0 : 26.1 us, 3.7 sy, 0.0 ni, 70.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 20.8 us, 0.0 sy, 0.0 ni, 79.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu2 : 22.2 us, 0.6 sy, 0.0 ni, 77.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu3 : 27.6 us, 0.3 sy, 0.0 ni, 72.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st I will rework my program now based on example-2 and hopefully the performance stays the same. Thanks, Bart P.S. I don't see any pictures in your previous post. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AITzwBEBSHedOIkJOdIvH7lA3yfC1vzVks5uQAOfgaJpZM4VvVAX> .

Yes, Jan, please log in to github.com — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AITzwJHnIAw-FQC8pHCDLSYRc6wYxlEbks5uQBWTgaJpZM4VvVAX> .