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