• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Recording
  • Assigned To
  • Operating System All players
  • Severity Low
  • Priority Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by MikeS - 2006-10-02

FS#6106 - Major SWCODEC Recording Update

Adds new functionality to recording for SWCODEC:
1) Adds samplerate support for all codecs
2) Adds samplerate playback and record support for Coldfire
3) Select for recording format
4) Individual encoder menus where applicable
5) Delayed file creation (up to 16 in waiting) with the option to start each new file immediately if desired.
6) More advanced encoder framework
7) Means to specify samplerates for targets with minimal changes to other code
8) A plugin to check samplerate switching on playback (maybe include this in CVS as a dev plugin?)

What I really really really need checked here is sample rate switching for uda1380 (iRiver). I know it works on the x5 just fine. The plugin is called sampr_test and will start by playing an A at 44100Hz. Changing the selection should change the pitch in proportion to the sample rate (octaves) if things are working. There should be no strange artifacts when doing this (some clicks maybe but x5 is seamless).

88.2kHz monitoring during recording on the x5 does not work and this recording rate will not be included if this issue cannot be resolved though recording itself at 88.2 does in fact work fine on x5.

There are finer issues to be worked out but not for stability…just fine tuning really and then syncing upcoming iPod recording with this which I will help with.

In summation:
I’m basically looking for iRiver owners to try this and report back about the sample rates. For x5 it’s a go. Others can be check to be sure there are no I’ll effects from the changes though nothing should really majorly change for anything other than x5 and iRiver.

Thanks in advance to all who take the time to test and comment but bear in mind I’m not looking for feature requests at the moment as that will be better to work on with this in CVS first. There are things I’d like to add myself. :)

Closed by  MikeS
2006-11-06 23:40
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Changes are committed now

I am reporting that selecting 11kHz samplerate freezes my iRiver H140. This happens from the plugin and the recording menu.

All else seems to be working correctly! I recorded 60 audio files from the internal mic. After transferring them to my PC foobar2000 tells me that it’s all working properly. Except samplerate = 11kHz of course.

Very very cool work Mike!

I tried this patch on my IAUDIO X5L 30GB, and had some difficulties:
-Voice menus not talking anymore,
-Disk did not spin down,
-When I went to the record screen and tried to start a recording, it
said my disk was full… but there’s 16G free on there…

That was built with some CVS from around Oct 3-4-5 (sorry), and no other patch.
I hope you can make something of this.

I’m new to Rockbox, got my player only this week, so please forgive me
if I’m missing something obvious. Did this depend on some other patch perhaps?


MikeS commented on 2006-10-07 03:06


More details would help. This sounds like a WavPack problem that has since been fixed. There was a problem where the unused data was’t being cleared at the start and overflow for high rates. I don’t know how your X5L could really act any differently than my x5 60GB so I figure you’d have to experience similar problems under similar conditions.

Recording assumes any error that is reported during recording is a disk full problem. This is no longer the case with codec recording. The error was likely due to the encoder flooding the flushing thread and corrupting the data when the buffer overflowed. This is checked for and data is dropped in that case but it never gets full anymore even with 88.2 WavPack. (WavPack encodes better than it plays back :)

Voice menus are shut down during recording BTW but do come back on. It would not be good to swap out the encoder to play voice when encoding since it would increase the likely hood of data loss.

petur commented on 2006-10-07 22:18

does voice work during pre-rec?

The reason I ask is that we have several blind users, and having a voiced recording screen has long been a request that was implemented several months ago - seems the encoding framework killed that.

pre-recording in uncompressed buffer still seems the logical thing to do, you can still disable voice when actually recording

btw, do post your updated patch….

MikeS commented on 2006-10-08 04:08

There’s been talk about using a built in codec for voice (speex?) and getting rid of swapping between voice and encoder would aid that. I will soon experiment with allowing the swapping since it hasn’t really been tried out. Having to have an encoder catch up from up to 30s behind is a bit of scary thought esp at 88.2 or 96kHz and esp. if doing WavPack. :)

There will be full duplex enabled so playing back something else during recording will be possible mainly for writing DSP plugings. Some seeds are planted for that in the next version of the patch.

I’ll post the patch real soon. I changed it to not entirely reset every chunk header after use since that shouldn’t be needed but have to be sure everything is working alright. I also changed the manner in which the iRiver pcm sample rate switching is configured and hopefully the whole list will work *praying*. I’m looking for a good deal an H1x0 ATM so I can test the SPDIF and UDA myself to speed up things when changing code around.

MikeS commented on 2006-10-08 17:49

Details, details:
- Changed the iRiver sample rate code so hopefull it will all work now.
- Did some other updates that should add stabiliy to the stream splitting…not every case was covered before.
- Added thread boosting when very full and spinup-time sensitive watermark for flushing data.
- Added seeds for full duplex audio to pcm_playback.c which pcm_record.c uses for samplrate and source switching.
- Added lots of logf if you like to watch that on remote so you can see if it’s indeed doing what I claim :)
- Added asynchronous stops so UI doesn’t do dead after when stopping
- Added thread_get_priority and thread_set_priority returns old priority (need that for prio boost)
- More tweaking to wavpack_enc
- Simplified audio format declaration in id3.c. No array left in metadata.c and all are together for easy maintenence.
- Moved encoder decs and datatypes to enc_base.h including the function decs. for encorder only pcm_record apis.
- Samplerate arrays in pcm_sampr.h and pcm_sampr.c are automatically generated with a few flags in your config*.h
- encoders should be able to work on little endian devices as well
- no more cfg file for the encoders so no disk spinup when changing formats
- Much more important minutae…

MikeS commented on 2006-10-08 17:51


Should probably reset your settings to make sure because I don’t know if it’s synced with the config block version anymore. I’ll do that just before a commit.

Full update! Not just main binary!

petur commented on 2006-10-08 22:02

unless I’m doing something wrong, this patch doesn apply cleanly against current CVS

MikeS commented on 2006-10-09 04:40

That’s strange. I update just before creating it. I’ll try again.

MikeS commented on 2006-10-09 05:55

The problem was that I have my editor set the turn tabs into four spaces and there are apparently some files in CVS that are using tabs and these diffs got in the patch. When I cleaned out the lines starting with “?”, the tabs in the patch were of course turned into spaces and it wouldn’t patch anymore of couse. I think the -l option ignores whitespace changes. This one is a diff with everything left as cvs diff produced it and works fine with up to the minute CVS.

petur commented on 2006-10-09 06:25

much better, thanks

I’ll try to load it on my h340 before leaving for work so I can test there a bit

MikeS commented on 2006-10-09 06:33

Man do a quick test with the sampr_test plugin because the sound chip configuration on the iRivers was totally changed and I can’t test it myself. It’s a major anxiety point about it atm. :0

MikeS commented on 2006-10-09 06:44

I say that cause it might not even play if I have it wrong. :)

petur commented on 2006-10-09 07:10


W A R N I N G: this patch breaks playback on iriver h1x0 and h3x0!!!


sure was a quiet ride to work on the bike…

MikeS commented on 2006-10-09 12:54

Should definitely fix the playback problem. LinusN helped sort that out. Maybe the recording will get audio now. There was an exception leaving the recording screen when he was testing but we’ll see.

MikeS commented on 2006-10-13 12:59

Just a resync of version 2.2 with current CVS.

MikeS commented on 2006-10-16 23:36

Another resync to CVS

MikeS commented on 2006-10-20 00:31

My chick s#1t solution to the slave mode monitoring problem on iRivers. :)
The chip should be setup like currently when recording except the unneeded (right) ADC is turned off when using mic.

I’ll put up a patch for debugging recording in slave mode when a commit happens.


Available keyboard shortcuts


Task Details

Task Editing