WARNING: current CVS recording code not stable [ NOW FIXED! ]

[petur]

a recent recording made with current CVS has (up till now, I'm listening at it now) at least two times  missing samples (quite a number of them even)

So be warned that this can happen at the moment!

edit: Code has been changed, testers wanted - all seems well

[Davide-NYC]

Oi!

Let me know if I can be of assistance with regard to this matter.

 

[petur]

you can always test and confirm, because I've done one or two good recordings with that version (I think - I'm changing versions too much)

glitches appear at a multiple of the buffer fill time, look here:
http://www.rockbox.org/tracker/task/6109

[Dhammavijaya]

Can someone report back when stabilised?

[petur]

sure...

not yet!

[mikecouk]

I had the same problem recording from optical in to 320kbps mp3 with AGC on.
I've turned AGC off and gone down to 196kbps mp3 and the problem has gone away.
You could always try one of the above to see if that solves you're problem in the meanwhile.

Mike

[dwonk]

Is there is some way we can standardize a recording stability test in current CVS versions for this type of problem?  Maybe start a thread reporting the stability of current versions so people needing reliable versions don't end up missing important recordings?

Petur, how long into the recording did you notice dropped samples?  

[petur]

I made one of 30 minutes and one of 90 minutes with no problems at all, and then one of 90 minutes where there were missing samples after 5 minutes already...

I'm beginning to think it's a glitch: my disk is getting full (6GB left) and is probably highly fragmented (installing several new rockbox versions almost every day). So it may have needed just a bit more time to save the buffer than the buffering system clould handle.

I'm looking forward to testing Mike's patch when he gets everything working

[pabouk]

This leads to the question whether the recording buffer flush watermark should be configurable in a similar way as the anti-skip buffer for playback.

[jhMikeS]

For one thing you shouldn't skip around with your player while recording!  

The stereo WavPack at 88.2 flushes in about 1sec when it reaches the panic point (1s remaining). This is the only format and frequency which I have seen reach this point but if somehow flushing is falling behind this will prevent an overflow. There's plenty of slack space in the PCM buffer (11s at 44.1 kHz) for audio data to build up. This could adapt to pcm frequency and allow more slack at high rates but doesn't appear to be needed. I've recorded 45 minute 88.2kHz stereo wavpacks without any loss. They can't play back but that's a playback problem. The files decode correctly with FooBar2000.

If the player is shaking vigorously that can prevent ATA from writing data but I was walking around recording radio when I recorded those files so some modest movement should be allright.

EDIT: I'll mention as well that the drive spinup time is taken into account now. The remaining time to flush is 5sec + spinup time. Before a spinup might take 3s leaving only 2s remaining before overflow.

[redwood]

Is there any news regarding the recording stability of the latest daily builds?

thanks

jp

[jhMikeS]

Yes, code changed on Nov 5. There's a couple issues:

1) Will be fixed in a day or so: After recording with S/PDIF on, then turning it off in the Playback settings, it will keep turning back on again when playing files.

2) Not sure what sample rate should be displayed for S/PDIF in the status bar: the rate recording measured when first started, the rate the encoder is using, or the current live rate. Under certain conditions all three can be quite different. I changed it to display the rate last measured and recording is assuming it still is the rate it measured when initializing. You could enter the screen at 96kHz with mp3 as the format, mp3 will have to use 48kHz since that's the highest sample rate it supports. The input could then go to say, 44.1Khz. You'll have three different rates being used in different parts. The digital rates will be rounded to the nearest the encoder accepts with a bias toward a higher one if it's right in between and nothing can be done about that. WAV and WavPack will accept any rate at all though.

I plan on adding the ability of codecs to switch and hopefully even do file splits (not sample-accurate, that's impossible) when the spdif rate changes in mid stream.

[Davide-NYC]

Not sure what sample rate should be displayed for S/PDIF in the status bar: the rate recording measured when first started, the rate the encoder is using, or the current live rate.

Prior to the filesplit feature I vote for simply showing the original incoming samplerate in the recording statusbar.  If it changes during recording maybe it should blink?  Thus promting the user to stop (at that point the statusbar would display the correct samplerate) and restart the recording.

-------------------------------------------------------------------------------------------------

WRS idea 1:

Adding another line to the WRS (while recording screen) displaying the currently selected input source would solve this confusion. During optical input it could also show the incoming samplerate (live).

Leaving the Samplerate in the statusbar to show the encoder's samplerate (that's what it shows when not recording from optical, right?) and showing the live samplerate in the new WRS line.

This way the recording statusbar behavior stays consistent across all inputs.

This idea presumes the filesplit-on-samplerate-change feature is implemented. Once it is I would no longer see the benefit of just showing the original samplerate.

-------------------------------------------------------------------------------------------------

WRS idea 2:

I have an idea to make all of this consistent across all targets *and* remotes!

"Hide" the Size and Filename lines behind the (new) Input and Time lines.
When the Volume line is selected (the top-most selectable line) and the user presses and holds the "UP" button, the Input and Time lines would be swapped on the display! On release of the "UP" button the display would return to normal.

This would *increase* the information displayed in the WRS by one line yet *reduce* the number of lines displayed in the WRS at any one time thus making it fit better on smaller displays.

I personally. Love this idea as it hide what I consider to be "less than essential" information from me during recording, (Filesize and Filename) yet doesn't remove it should I need to see it.

[fizze]

well I used koshs version from early october with the SWCODEC patch.
from what I get the issues were not present at low bitrates.
I recorded hours and hours in mp3 at 128 and 192 stereo.

works like a charm. I especially dig AGC.

I'll try to see what I can do to test the update from CVS.
As I only have a H300, the source display isnt an issue.
Nor is the remote, as normally during band rehearsals I just start the recording with AGC set to live (slow), and then after the rehearsal I just shut it off.

Also, I dont use the remote to record. And I dont think I will (ever).

[petur]

This weekend I did another long recording (yes it was a long time ago), and I've spotted two glitches in 70 minutes so far. Definitely better as last time but still unacceptable.

Be warned.