search

JvanKatwijk / dab-cmdline

DAB decoding library with example of its use
GNU General Public License v2.0
57 stars 29 forks source link

Improving performance on Raspberry Pi #45

Closed bartpeeters closed 6 years ago

bartpeeters commented 6 years ago

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:

Thanks in advance for the help.

JvanKatwijk commented 6 years ago

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 https://github.com/JvanKatwijk/dab-cmdline/issues/45, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwLk9rnK848g5us_iTsxYFWeOhJipks5uNs1FgaJpZM4VvVAX .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

JvanKatwijk commented 6 years ago

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 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 https://github.com/JvanKatwijk/dab-cmdline/issues/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 commented 6 years ago

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 commented 6 years ago

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 https://github.com/JvanKatwijk/dab-cmdline/issues/45#issuecomment-412333464, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwBEBSHedOIkJOdIvH7lA3yfC1vzVks5uQAOfgaJpZM4VvVAX .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355

andimik commented 6 years ago

Yes, Jan, please log in to github.com

JvanKatwijk commented 6 years ago

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 https://github.com/JvanKatwijk/dab-cmdline/issues/45#issuecomment-412337295, or mute the thread https://github.com/notifications/unsubscribe-auth/AITzwJHnIAw-FQC8pHCDLSYRc6wYxlEbks5uQBWTgaJpZM4VvVAX .

-- Jan van Katwijk

+31 (0)15 3698980 +31 (0) 628260355