Station just "dies" after playing a few songs

[HatKidTheHatLoli]

I have mpg123 piping in audio directly into PiFmAdv. There's a faint popping sound in quieter parts of the track, and after playing a little while, the signal just dies out into nothing but static. There are no errors on the output. mpg123 just sits there, and PiFmAdv seems to just cease in pulling data from the pipe. I'm on a Pi Zero W. No abnormal CPU usage either.

This may be related to #40 and #2, but it seems like theirs are transmitting longer than what mine is. I'm not even able to get more than 10-20 minutes of playtime before it just "crashes out" (again, no errors or odd noises, signal just goes poof and the system sits there). Hitting Ctrl-C closes both programs as if nothing was wrong to begin with.

[HatKidTheHatLoli]

Just updating but I've been able to get the station to hold for about an hour by adding a buffer to mpg123. But there's still no errors from when the signal just cuts out. No odd noises either.

[ghost]

It's a buffer under-run. If the wait flag is set (it is by default), fm_mpx_get_samples silently exits so there are no errors. The pipe is closed and not opened again because it's opened outside the main loop.

[HatKidTheHatLoli]

Yeah.. was pretty certain it was something along those lines. I dont suppose theres any workaround to it, other than just rebooting so often?

[ghost]

If you set wait to 0 it will exit with an error so you can restart it. I have modified the code so it keeps polling the pipe in the main loop, but it's not a good fix - you get stuttering while there is no data and the sampling rate can't be changed between streams. The code really needs to be refactored to implement it properly.

[HatKidTheHatLoli]

So I can just have a simple bash script that just relaunches mpg123 and pifmadv in an infinite loop, with the flag set to 0?

And yeah, I did read another issue that made mention that a major rewrite would be needed to fix the over/underbuffer issues. Kinda wished I understood these things a little better, I'd probably try taking a crack at fixing it otherwise.

[miegl]

You should be able to modify the code easily to reopen the audio file when needed. But the best solution is probably getting the audio and pifmadv in sync so that it doesn't happen. Variable sample rate isn't a good solution IMHO, it just sounds awful whenever it happens. I don't have time for that now though so you are free to experiment.

[rashrf]

Hi, Might the clock drift compensation implementation in odr-audioenc help? https://github.com/Opendigitalradio/ODR-AudioEnc/blob/7a50aff45d650e6bd143e52c58bc38221df1f43a/src/SampleQueue.h R.

…

On Tue, 6 Aug 2019 at 15:38, Josef Miegl ***@***.***> wrote: You should be able to modify the code easily to reopen the audio file when needed. But the best solution is probably getting the audio and pifmadv in sync so that it doesn't happen. Variable sample rate isn't a good solution IMHO, it just sounds awful whenever it happens. I don't have time for that now though so you are free to experiment. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#61?email_source=notifications&email_token=ABFIVYWUYICIIPD3WJQ27DLQDGEH5A5CNFSM4IJBZPH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VLL3I#issuecomment-518698477>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFIVYWBI3T7KGZ7QNCK563QDGEH5ANCNFSM4IJBZPHQ> .

[rashrf]

Oop. Line 318 onward, although that header has some useful comments. I shouldn't try to do two things at once - I am not multi-thread capable! https://github.com/Opendigitalradio/ODR-AudioEnc/blob/7a50aff45d650e6bd143e52c58bc38221df1f43a/src/odr-audioenc.cpp R. On Tue, 6 Aug 2019 at 16:38, Rashid Mustapha <rashid.mustapha@gmail.com> wrote:

…

Hi, Might the clock drift compensation implementation in odr-audioenc help? https://github.com/Opendigitalradio/ODR-AudioEnc/blob/7a50aff45d650e6bd143e52c58bc38221df1f43a/src/SampleQueue.h R. On Tue, 6 Aug 2019 at 15:38, Josef Miegl ***@***.***> wrote: > You should be able to modify the code easily to reopen the audio file > when needed. But the best solution is probably getting the audio and > pifmadv in sync so that it doesn't happen. Variable sample rate isn't a > good solution IMHO, it just sounds awful whenever it happens. I don't have > time for that now though so you are free to experiment. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#61?email_source=notifications&email_token=ABFIVYWUYICIIPD3WJQ27DLQDGEH5A5CNFSM4IJBZPH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VLL3I#issuecomment-518698477>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABFIVYWBI3T7KGZ7QNCK563QDGEH5ANCNFSM4IJBZPHQ> > . >

[HatKidTheHatLoli]

I honestly don't know. Maybe I'll see if I can possibly throw that in somewhere. I'm still unsure to how I'd do stuff like that, as this is some new territory for me, but just maybe.

[HatKidTheHatLoli]

I'd like to update that having the wait flag set to 0 does not display any errors. It doesnt seem to matter if it's set to 1 or 0, it still just cuts off at random. If I manually kill with Ctrl C, it will show the "cleanly deactivated the DMA carrier and killed the carrier" message. But it doesn't do that when the signal just fuzzes out. It's as if it's still half working or something.

[morrolinux]

I have to add that this happens to me as well, but only on my Pi 3. The Pi Zero W is perfectly stable.
Test conditions were the same, so I'm not entirely sure it's about an underrun

[miegl]

Your Pi 3 probably has just a bigger clock error. You can play around with the --ppm argument.