Open HatKidTheHatLoli opened 5 years ago
HatKidTheHatLoli
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago Hi,
Might the clock drift compensation implementation in odr-audioenc help?
R.
On Tue, 6 Aug 2019 at 15:38, Josef Miegl notifications@github.com 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 https://github.com/miegl/PiFmAdv/issues/61?email_source=notifications&email_token=ABFIVYWUYICIIPD3WJQ27DLQDGEH5A5CNFSM4IJBZPH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VLL3I#issuecomment-518698477, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFIVYWBI3T7KGZ7QNCK563QDGEH5ANCNFSM4IJBZPHQ .
rashrf
commented
5 years ago 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!
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?
R.
On Tue, 6 Aug 2019 at 15:38, Josef Miegl notifications@github.com 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 https://github.com/miegl/PiFmAdv/issues/61?email_source=notifications&email_token=ABFIVYWUYICIIPD3WJQ27DLQDGEH5A5CNFSM4IJBZPH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VLL3I#issuecomment-518698477, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFIVYWBI3T7KGZ7QNCK563QDGEH5ANCNFSM4IJBZPHQ .
HatKidTheHatLoli
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago Your Pi 3 probably has just a bigger clock error. You can play around with the --ppm argument.
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.