Rockbox

This updates the file open routine to use existing code. A few cleanups.

   wavwrite.patch (7.1 KiB)

This version limits the WAV output capability to simulator builds, which is where debugging DSP code is most useful anyway.

   wavwrite.patch (7.2 KiB)

Doesn’t the simulator already have this ability? I thought there was a –raw switch of something that caused the sim to dump the audio output to a file.

Ah, found it. You can use –debugaudio switch to the simulator and it will write the raw PCM samples to a file called audiodebug.raw in the current directory. Maybe you want to enhance that to write WAV files?

Thanks for the heads-up. I checked out the debugaudio routine, and it works almost the same. However for some reason it cuts off the last thousand or so samples when playback completes, or perhaps those last samples are never played and therefore aren’t written. The routine I wrote writes the output of the DSP routine, presumably whether it’s ultimately played out of the PCM buffer or not. One effect of this is that if no DSP effects are active, the output is a bit perfect copy of the input. The debugaudio routine is also bit perfect in this scenario, but it’s too short.

I could probably modify the debugaudio routine to output different filenames, and write a compliant WAV header. But if the purpose is to inspect the DSP output, it’s not good enough unless we can ensure all of the audio is written to disk.

If I remember correctly, the debugaudio stuff was introduced to also help with debugging buffering issues which is why at the end of the output chain. If it’s not writing the last set of samples, that sounds like a bug that should be fixed. From my perspective, it would be better to keep this sort of sim-only debugging stuff within in the sim code if possible.

I’ve been trying to hunt down the reason why the last samples are left out without success so far. It’s definitely not a codec issue because it will write out those last samples as long as the playback continues to another file. It appears only to be a problem when playback ceases at the end of the playlist. It’s almost certainly an issue with playback itself, as it not only isn’t writing out the last samples, it’s not playing them either. I’ll move the test file over to a real player to see if I can duplicate the problem there. Hopefully, this is limited to the simulator.

I will happily throw out my patch if I can get the existing code to work correctly. I agree that since the decision was made to make this a simulator only feature that the code is best left in the simulator code itself. If I do work this bug out, I’ll put the patch fixing the existing debug audio code here.

I just checked out my test file on an actual target, and it appears the the playback routine is buggy on the target also. So the simulator code is likely working correctly but the routine to play out the buffer at the end of the playlist is at fault. I’ll open a separate bug report for that.

Here’s a quick patch to the existing debugaudio sim code. It now closes the raw audio file properly when playback ceases, which allows opening the file in an external application with the simulator still operating, but not writing.

File output still varies from file input due to the unrelated playback bug mentioned above.

   debugaudio.patch (1.1 KiB)

The playback bug is now fixed and the debugaudio patch works correctly.

This looks interesting.