Page 1 of 1

Ogg playback

Posted: Tue 2018-12-04 0:38
by roy
I am using the VS1053. The code running on my processor is basically the player1053.c code with just the playback functionality - no user interface or recording, etc. I am loading the plugin vs1053b-patches-flac.plg from the The system is able to play WAV and MP3 files without issue. OGG files behave bizarrely. The attached ogg was created using vorbis-tools oggenc on a wav file. The vorbis-tools ogginfo tool provides the following description of the file:

[roy@royprimary buildToc]$ ogginfo 0530a324-206e-4149-9d84-cf9b20c4ae85.ogg
Processing file "0530a324-206e-4149-9d84-cf9b20c4ae85.ogg"...

New logical stream (#1, serial: 034473aa): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20180316 (Now 100% fewer shells)
Channels: 1
Rate: 48000

Nominal bitrate: 110.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 23864 bytes
Playback length: 0m:02.069s
Average bitrate: 92.233589 kb/s
Logical stream 1 ended

When I play the file on the system I just get a reverberation that appears to have no relation to the original file. The reverberation continues indefinitely - not for just over 2 seconds as the playback should be. When I play the file on Linux it sounds fine.
Audio file
(27.18 KiB) Downloaded 23 times
Any insights into what I need to do would be appreciated. A sample of a known good OGG file would be nice too.

Best regards,
Roy Cooley

Re: Ogg playback

Posted: Wed 2018-12-05 11:46
by pasi
The file seems to play fine with my vs1053b setup (with and without vs1053b-patches-flac), even with 1.0x clock.

I only write SCI_MODE to 0x4c00 because the setup requires shared mode, then send the file, respecting DREQ.

What's your CVDD?

Re: Ogg playback

Posted: Wed 2018-12-05 13:01
by roy
CVDD is 1.8vdc.

I have found a couple of WAV files that contain single tones which play back properly and I measure the right frequency on the scope.

Why did you ask about CVDD?

Thanks for confirming the file is valid that eliminates one consideration.

Setting of SCI_MODE seems to be specific to your hardware setup. I tried adding it to be sure but it did not help.

bool VS1053PlayFile(FileReadAudio *readFp) {
static u_int8 playBuf[FILE_BUFFER_SIZE];
SpiError = false;
u_int32 bytesInBuffer; // How many bytes in buffer left
u_int32 pos=0; // File position
int endFillByte = 0; // What byte value to send after file
int endFillBytes = SDI_END_FILL_BYTES; // How many of those to send
int playMode = ReadVS10xxMem(PAR_PLAY_MODE);
long nextReportPos=0; // File pointer where to next collect/report
int i;

playerState = psPlayback; // Set state to normal playback

WriteSci(SCI_MODE, 0x4c00); // !!! I tried adding this based on your comment

if (SpiError) { return(false); }

// Main playback loop
unsigned int dbgRdCtr = 0;
unsigned int dbgTotBytes = 0;
unsigned int bytesRead;
while ( (!audioFileEOF(readFp)) &&
(FA_OK == audioFileRead(readFp, playBuf, FILE_BUFFER_SIZE, &bytesRead)) > 0 &&
(playerState != psStopped)
) {

Re: Ogg playback

Posted: Wed 2018-12-05 13:40
by pasi
roy wrote:
Wed 2018-12-05 13:01
CVDD is 1.8vdc.
Why did you ask about CVDD?
Because if CVDD is over the max rating (much above 1.95V, perhaps 2.5V due to migration from an earlier generation) the memory of vs1053 starts to fail, which would explain crashes with some decoders while some might be working.

SCI_MODE of 0x4c00 is specific to my setup which only uses one chip select signal. If you use xCS and xDCS, then the reset value for SCI_MODE works (and you should not set the SCIMB_SHARED bit).

There might still be some issue with the data transfer over SDI (like changing chip select while the SPI transfer is active). Do all WAV files play? If you use only mono 8-bit, you may not notice missing or inserted bytes, and mp3 is also able to resynchronize if there are extra bytes.

Re: Ogg playback

Posted: Wed 2018-12-05 15:02
by roy
Thanks for pointing me in the right direction. The issue was with the SDI data transfer. The DREQ was not being respected properly.