Improving performance on Raspberry Pi

[bartpeeters]

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.

[JvanKatwijk]

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 <notifications@github.com>:

…

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

[JvanKatwijk]

Bart I ran example 2 on an RPI2 and an RPI 3B, the loads are given in the pictures attached Please do the same in your environment (you might have to eliminate a ine in the main program (line 259 std::wcout.imbue(std::locale("en_US.utf8"));) that seems to give trouble on the RPI. If in your case the load is completely different, then we can start from there to address the issue If the load is more or less what is expected, then we should do the exercise with example 4. 2018-08-05 14:58 GMT+02:00 jan van katwijk <j.vankatwijk@gmail.com>:

…

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

-- Jan van Katwijk +31 (0)15 3698980 +31 (0) 628260355

[bartpeeters]

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.

[JvanKatwijk]

It seems mailing using replies over github looses the pictures 2018-08-12 12:29 GMT+02:00 Bart Peeters <notifications@github.com>:

…

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> .

-- Jan van Katwijk +31 (0)15 3698980 +31 (0) 628260355

[andimik]

Yes, Jan, please log in to github.com

[JvanKatwijk]

I did 2018-08-12 13:46 GMT+02:00 andimik <notifications@github.com>:

…

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> .

-- Jan van Katwijk +31 (0)15 3698980 +31 (0) 628260355