OggVorbis recording produces "Broken" file

NETMF & Gadgeteer
1

Hi All,

Trying to use the EMX Development kit to record a stereo line input using the VS1053. Using the music shield example provided:
[url]http://code.tinyclr.com/project/330/fez-music-shield/[/url]
The code has been modified to work with the EMX hardware and the sparkfun bob.

It initialises the VS1053 ok, and recording starts successfully, samples are read and written to the onboard SD card. The recorded sound file plays (on computer) parts of the recorded sound but then breaks off into silence, only to be followed by another short burst of clear sound…

Examining the file with ogginfo.exe shows the header is OK, but reports “Hole in Data” faults.

Here is the recorded ogg file:
[url]http://dl.dropbox.com/u/35359304/20110715T132504.ogg[/url]

To ensure that it is not a problem with slow write delays to the SD card I modified the code to store the samples in a large (768KB) buffer and then write this to the SD card, but the result is the same.

Any ideas as to how to get around this?

2

Maybe you are not reading the MP3 chip fast enough? Do you have other threads running?
It works fine on FEZ Panda so it should be fine on EMX.

3

Mike, the code is very close to the original example with only two threads running, the main and recording loop.

Looking at the SPI bus with an analyser shows that the SPI clock is running at 2MHz (as intended) with a gap of approximately 0.7ms between chip selects.

4

Not sure what could be the problem. Please try the original example as is and see if it works.

5

Tried the original (again modified to work with emx dev kit). Same problem.
Here is the ogginfo analysis:

New logical stream (#1, serial: 12345678): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: VLSI Solution Oy
Channels: 1
Rate: 44100

Nominal bitrate: 39.000000 kb/s
Upper bitrate not set
Lower bitrate not set
User comments section follows...
        ENCODER=VS1053 v1.70
Warning: Hole in data found at approximate offset 13500 bytes. Corrupted ogg.
Warning: sequence number gap in stream 1. Got page 9 when expecting page 4. Indi
cates missing data.
Warning: Hole in data found at approximate offset 27000 bytes. Corrupted ogg.
Vorbis stream 1:
        Total data length: 15871 bytes
        Playback length: 0m:11s
        Average bitrate: 10.615007 kbps
Logical stream 1 ended

Also approx how long should the patch take to load? It seems to take around 19s on my test.

6

You said that you tried buffering the data in a big buffer and still does not work? I am not sure what else you can try. There is a commented debug.Print() that prints how many samples are buffered in the chip. Print that and see if it is always full. Maybe you have to take a closer look at the chip datasheet to see what is going on.

The patch is big and requires a lot of processing so it will take long time. You can try to preprocess the data or use RLP to make it faster.

7

Try to load different ogg plugin/patch with a lower sampling rate, see if it makes a difference.

8

That works up to the 8KHz - “venc08k1q06.plg” profile (thanks architect!), but anything with higher sample rate/quality produces the same faulty audio file.
With the 8KHz profile samples arrive at a steady rate, around the 2000 mark. Whereas with the 16KHz (and above) the sample rates are much more sporadic and approach 3800 samples, which is very near the buffer of the audio chip. This obviously means that the EMX is not reading the buffer fast enough, and this allows the buffer to overflow, creating the “Hole in the data”. Im surprised that this sample code works in the panda and not the EMX.

Is there any other options available to speed up the thread without using RLP?

9

I personally think the problem is in the decoder. Maybe you need to increase its clock?

10

The VS1053 is running at its maximum clock speed (4.5x PLL - 55.3MHz) as per the example.

I believe the issue to be with the SPI Class. Running the following piece of code against a logic analyser shows that the chip select time is 35us, but the time between a pin going high at the start and end of the loop is 0.87ms. It must be the spi.WriteRead method that has this relatively long delay. This does not seem right to me.

while (i < nSamples)
{
audio_read.Write(true); //While-loop (Pin High)
_spi.WriteRead(_sampleBuffer, 0, 2, _recordingBuffer, bufferIndex, 2, 2);
i++;
bufferIndex += 2;  //Large 768Kb Buffer
audio_read.Write(false); //While-loop (Pin Low)
}

Please see the image for analysed signal.

11

so total delay is about .87 ms which is 870 us. I think this is normal for 3 native invocations in the code overhead + SPI overhead.
SPI will perform much better if writing/reading data at bigger chunks (if the slave chip allows it).

If no other threads are running and still cannot keep up, RLP might be the best option.

12

Unfortunately the VS1053 must be read 1-word at a time.

One thing still confuses me however, how does this work on the FEZ Panda, but not the EMX?

1 Like
13

@ D Procter - Hello, I’ve got same problem one year later… did you find any solution to this matter?

Regards,
Gianmaria