Support and General Use > Recording

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

<< < (2/11) > >>

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!  ;D

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page