Malfunction after 3-4 hours

[Niall7459]

The program seems to malfunction after around 3 to 4 hours.

A high pitched constant noise is made after several overruns.

Original PiFmRds did not make this noise and would just exit the program, which was better because I had the program in a loop, so it would just start again.

Please try and get this fixed, it would make the program perfect!
Thanks!

[miegl]

Hi,
I don't have much time now but I will try to test it as fast as I can.
Yet I don't know what you mean by "high pitched noise". Maybe you mean the noise that gets generated by the RDS data generator, which is PiFmRds bug and I will try to fix it asap.
However, I dont see a problem with the software waiting for input instead of exiting. Take this situation for example: you are piping data thru sox, then suddenly audio input (for example icecast/shoutcast) lags for a while. The software will wait for input, instead of exiting, which is pretty handy in my opinion.

[Niall7459]

Oh ok so that is a handy option, then must be a problem with my VLC ?

[Niall7459]

Sorry, I didnt mean the audio input cuts out. Im old PiFmRds I after 3-4 hours I used to just hear the music Skipping, like a stuck CD for about 3 mins, and then a restart with "Failed to rewind in audio file. Terminating. " But with PiFmAdv, It just leaves the high pitched noise going.

MY PiFmAdv is listening through Alsa, which VLC is playing to.

[miegl]

Ok, I ran PiFmAdv for few hours and it got "stuck". No RDS data was generated and I heard, as you said, high pitch noise.
But to be honest, I don't know how to fix it yet. Thanks for the bug report tho.

[Niall7459]

I suggest finding where the errors happening first. unless you already know.

[miegl]

I have currently no idea why it does this. Maybe something is wrong in DMA?

[miegl]

Well I would like to post some progress report.
Firstly, I still don't know what is causing this to happen. The only thing I know about this, is that the CPU usage on my RPI2 drops from about 32% to 5.2%. The allocated memory stays the same.
The only thing that I can think of is some DMA & memory error. (because of the "stuck" noise that it is producing, its identical to the "stuck" state when PiFmAdv gets closed but the DMA engine is left running.)
I'm sure I will need some help with this bug. I'm not quite experienced in developing stuff for RPI.
For now you can write a script which will restart PiFmAdv every 2 hours or so.

[miegl]

You can you this simple bash script:

#!/bin/bash
while :; do
        ./pi_fm_adv &
        pid=$!
        sleep 2h
        kill -2 $pid
done

Pay extra attention to the kill -2 parameter; this will send SIGINT signal to the PiFmAdv, which will then safely stop DMA engine. If we would kill PiFmAdv with SIGKILL signal (parameter -9), there is a chance something will go wrong since the DMA engine will not be stopped.
Also, I don't know yet if the error is in the DMA itself, so I highly suggest shutting down PiFmAdv and its DMA engine safely.

The script will restart PiFmAdv (feel free to add your own parameters & pipe input) every 2 hours.
I also recommend adjusting the -ppm parameter. Wrong calibration could cause delay in sound between restarts.

[miegl]

Ok, so the bug still persists. I think I need some help with this one.

[Niall7459]

@miegl I might apply that patch from SaucySoliton PiFmRds to allow change DMA Engine.
Is there a quick command I can use ? to apply that commit to PiFmAdv

[VincentBruinink]

Ok, so the bug still persists. I think I need some help with this one.

@miegl

This is a sync problem. If you use a wave file as input then the DMA engine can request as much samples it wants, whenever it wants until the end of the file. If you use a webstream you need to put the data in a ringbuffer. Then the DMA engine has to keep track of the length of the written samples in the ringbuffer and adjust the output samplerate so that the buffer would not overflow or underflow.

The input samplerate from the webstream is fixed. For example 44.1kHz. The output samplerate of the DMA is also fixed at 228kHz. over time both will get out of sync. You have to handle the input stream as master because the samplerate is fixed. Then adjust the output samplerate so both remain in sync.

[Niall7459]

Wow, it’s been such a long time since I’ve been on this repository. Although I did get a temporary fix in the end, which was to run PiFmRds in a loop, and have another script kill the process after about 3 hours, this worked great for me and you can barely notice (you may want a slight delay when restarting PiFmRds in case of any errors) although an official fix would be nice.

Good luck!

[0d0a]

You can you this simple bash script:

#!/bin/bash
while :; do
        ./pi_fm_adv &
        pid=$!
        sleep 2h
        kill -2 $pid
done

Pay extra attention to the kill -2 parameter; this will send SIGINT signal to the PiFmAdv, which will then safely stop DMA engine. If we would kill PiFmAdv with SIGKILL signal (parameter -9), there is a chance something will go wrong since the DMA engine will not be stopped.
Also, I don't know yet if the error is in the DMA itself, so I highly suggest shutting down PiFmAdv and its DMA engine safely.

The script will restart PiFmAdv (feel free to add your own parameters & pipe input) every 2 hours.
I also recommend adjusting the -ppm parameter. Wrong calibration could cause delay in sound between restarts.

I am Trying to use the bash script, but as I use Sox to capture a stream the script needs modifying .. anybody knows how?