vs1053b plaing too fast

Writing software that inputs and/or outputs audio and performs DSP algorithms such as filters, new codecs or audio effects.
Post Reply
hobbes88
User
Posts: 16
Joined: Mon 2015-05-11 0:58

vs1053b plaing too fast

Post by hobbes88 » Fri 2016-02-26 3:47

Hi,

After a bit of a break I am back and need some help. Pasi and Panu helped me out the last time.

I am using a Beagle Bone black to talk to a LC Soft / VS1053b board. The midi works well, and I have reset it into MP3 mode and have managed to get sounds out of the board. The problem is when I play a MP3 file it plays very fast. It is as if someone was pressing fast forward.

Here is some information. From ffprobe there is some file information on the MP3:

[papa@calvin2 force_music]$ mp3info forcemusic.mp3
{
"streams": [
{
"index": 0,
"codec_name": "mp3",
"codec_long_name": "MP3 (MPEG audio layer 3)",
"codec_type": "audio",
"codec_time_base": "1/44100",
"codec_tag_string": "[0][0][0][0]",
"codec_tag": "0x0000",
"sample_fmt": "s16p",
"sample_rate": "44100",
"channels": 2,
"channel_layout": "stereo",
"bits_per_sample": 0,
"r_frame_rate": "0/0",
"avg_frame_rate": "0/0",
"time_base": "1/14112000",
"start_pts": 353600,
"start_time": "0.025057",
"duration_ts": 1717862400,
"duration": "121.730612",
"bit_rate": "109631",
"disposition": {
"default": 0,
"dub": 0,
"original": 0,
"comment": 0,
"lyrics": 0,
"karaoke": 0,
"forced": 0,
"hearing_impaired": 0,
"visual_impaired": 0,
"clean_effects": 0,
"attached_pic": 0
},
"tags": {
"encoder": "Lavc56.26"
}
}
],
"format": {
"filename": "forcemusic.mp3",
"nb_streams": 1,
"nb_programs": 0,
"format_name": "mp3",
"format_long_name": "MP2/3 (MPEG audio layer 2/3)",
"start_time": "0.025057",
"duration": "121.730612",
"size": "1668332",
"bit_rate": "109640",
"probe_score": 51,
"tags": {
"major_brand": "isom",
"minor_version": "512",
"compatible_brands": "isomiso2mp41",
"encoder": "Lavf56.25.101"
}
}
}

Then while the music is playing fast here is a dump of the registers from the VS1053

26533: [2016-Feb-25 20:23:04.327024] - vs1053 dreq 0 2378
26534: [2016-Feb-25 20:23:04.327327] - dreq.cpp 97 0 2378
26535: [2016-Feb-25 20:23:04.335348] - vs1053 dreq 1 2379
26536: [2016-Feb-25 20:23:04.335610] - dreq.cpp 99 1 2379
26537: [2016-Feb-25 20:23:04.335909] - play.cpp 109 DID wait pause
26538: [2016-Feb-25 20:23:04.336120] - Dumping VS1053 Registers
26539: [2016-Feb-25 20:23:04.336307] - Mode 0x0 = 0x4800
26540: [2016-Feb-25 20:23:04.336609] - Stat 0x1 = 0x40
26541: [2016-Feb-25 20:23:04.336854] - Bass 0x2 = 0x0
26542: [2016-Feb-25 20:23:04.337087] - Clkf 0x3 = 0x8800
26543: [2016-Feb-25 20:23:04.337323] - Decode time 0x4 = 0x2
26544: [2016-Feb-25 20:23:04.337561] - AuData 0x5 = 0xac45
26545: [2016-Feb-25 20:23:04.337800] - Wram 0x6 = 0x0
26546: [2016-Feb-25 20:23:04.338035] - Wram addr 0x7 = 0x1e29
26547: [2016-Feb-25 20:23:04.338272] - Hdat 1 0x8 = 0x7064
26548: [2016-Feb-25 20:23:04.338507] - Hdat 2 0x9 = 0xfffb
26549: [2016-Feb-25 20:23:04.338744] - AiAddr 0xA = 0x0
26550: [2016-Feb-25 20:23:04.338978] - Vol 0xB = 0x0
26551: [2016-Feb-25 20:23:04.339212] - AiCrtl0 0xC = 0x0
26552: [2016-Feb-25 20:23:04.339446] - AiCtrl1 0xD = 0x0
26553: [2016-Feb-25 20:23:04.339681] - AiCtrl2 0xE = 0x0
26554: [2016-Feb-25 20:23:04.339911] - AiCtrl3 0xF = 0x0

I checked that I am waiting on DREQ. I have it as a GPIO-Keys that flag an event, and have a linux pthread event thread that acts as an Interrupt service routine. Just for the sake of completeness I also check the common parameters to make sure playspeed is not set to super fast.

6672: [2016-Feb-25 20:22:40.671717] - Dumping VS1053 common parameters
6673: [2016-Feb-25 20:22:40.673226] - Version 0x01e02 = 0x3
6674: [2016-Feb-25 20:22:40.674243] - Config1 0x01e03 = 0x0
6675: [2016-Feb-25 20:22:40.675440] - Playspeed 0x01e04 = 0x0
6676: [2016-Feb-25 20:22:40.676513] - Byterate 0x01e05 = 0x0
6677: [2016-Feb-25 20:22:40.677628] - Endfill 0x01e06 = 0x0
6678: [2016-Feb-25 20:22:40.678651] - Resync 0x01e29 = 0x0

For some reason the chips seems to play at a very very fast rate, I would say 4x or more.

Any ideas?

Many thanks Mike.

User avatar
pasi
VLSI Staff
Posts: 1416
Joined: Thu 2010-07-15 16:04

Re: vs1053b plaing too fast

Post by pasi » Fri 2016-02-26 11:30

The regular suspects:
- Something wrong in DREQ handling: check for DREQ=1, then send 32 bytes of data.
- Don't change the chip select signals while the SPI is transmitting, otherwise bytes go missing. (See that SPI is idle before changing the chip select signels.)
- Other chip select issues, extra bytes are inserted to SDI.
- You are reading blocks as words but sending them as bytes, sending only half of the data
- Filesystem issues, not sending all blocks.
- The parametric_x.playSpeed variable has been set somehow.
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

hobbes88
User
Posts: 16
Joined: Mon 2015-05-11 0:58

Re: vs1053b plaing too fast

Post by hobbes88 » Fri 2016-02-26 14:18

Hi Pasi,

Thanks for your kind tips. I did check DREQ, and the code I think is working OK. on that point. SPI wise I think I am OK. The way the Chip selects are handled is there are two devices in /dev. In the BeagleBone black I have set my device tree to Share an SPI, but with two Chip selects. This allows the AM338 TI Sitara ARM chip to handle the chip selects for me. So unless I have another thread grabbing the other device in /dev I think overlapping Chip selects is not the issue.

The Parametric play speed is zero.

6672: [2016-Feb-25 20:22:40.671717] - Dumping VS1053 common parameters
6673: [2016-Feb-25 20:22:40.673226] - Version 0x01e02 = 0x3
6674: [2016-Feb-25 20:22:40.674243] - Config1 0x01e03 = 0x0
6675: [2016-Feb-25 20:22:40.675440] - Playspeed 0x01e04 = 0x0
6676: [2016-Feb-25 20:22:40.676513] - Byterate 0x01e05 = 0x0
6677: [2016-Feb-25 20:22:40.677628] - Endfill 0x01e06 = 0x0
6678: [2016-Feb-25 20:22:40.678651] - Resync 0x01e29 = 0x0

I check by reading it out and it is set to zero.

I think my MP3 file is a wrong format. The MP3 file I have plays fine on an AMD 64 bit Intel X86-64. This is a Little Endian box. I take that same file and sent it Byte by Byte to the VS1053. I.E.

Step 1: Read the whole file in.
Step 2: Send the whole file out, while observing DREQ.

You are right in that it could be the word / byte / endianess file format. I know there are lots of ways a MP3 can be encoded, but the file I have is "sample_fmt": "s16p",. So this is signed 16 bit planar.

Does the VS1053 expect a MP3 planar format, as opposed to non-planar MP3?
When I send a s16, signed 16 bit sample, does that mean it needs to be byte swapped?

For my SCI writes, I byteswap the 16bit data. I.E. I assume the VS1053 is Big endian. I need to send the most significant Byte first in a 16 bit word. This works well and I get the correct responses and can dump out the registers in the VS1053.

In sending SDI (data), I simply read the file and send that at the VS1053. That is in AMD / Intel / x86-64 format. Do I need to byte swap every 16 bit word?

What confuses me a bit is if I send a wave file with a RIFF header. That file is signed 16 bit. I understand that by swaping bytes the 16 bit samples will come out right. But what will happen to the header? Won't R I F F then become I R F F? I guess looking at page 52, of the VS1053 ddata sheet (Version 1.22, 2014-12-19 ) It needs to see R I F F, and the header is in little Endian. i.e. for Bits per sample = 16, we send 0x10 then 0x00. I.E. we send the least significant Byte first.

Sorry for the rambling message. Just a bit confused as to why ....

So to end here are some simple questions.

1) VS1053. What does it expect the Mp3 format to be in endian wise. Little Endian like Intel AMD x86 boxes, or Big Endian like Power PC chips?
2) Do you have a known good MP3 file I can download and use to test, or a link to one?
3) If I am using FFMPEG on Linux on an Intel box, do you have a command line that will produce a MP3 file I can play on the VS1053. I.E. what are the command option settings I should set.

Thanks again for your kind help.

Best, Mike.

User avatar
pasi
VLSI Staff
Posts: 1416
Joined: Thu 2010-07-15 16:04

Re: vs1053b plaing too fast

Post by pasi » Fri 2016-02-26 14:43

All the data in the SDI should be considered sent as bytes (although they are internally collected into words). The first byte in the file should be sent first, MSb first, then the rest of the bytes in the file in sequential order.

If you hear anything from the mp3 file, you have things basically correct.

Is your XTAL 12.288MHz?

Could you attach (or send to support@vlsi.fi) a short mp3 for me to test?
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

hobbes88
User
Posts: 16
Joined: Mon 2015-05-11 0:58

Re: vs1053b playing too fast

Post by hobbes88 » Fri 2016-02-26 15:19

Hi Pasi,

Thanks for the info. You are correct. I do hear mp3 music, just way too fast with clicks. But you can hear the tune....

I think it may be the Xtest pin floating problem. I have the same board from E-bay as this guy

http://minhdanh2002.blogspot.com/2013/1 ... coder.html

It is an LC-Soft one.

Would a flakey Xtest pin cause the symptoms I am observing? I noticed some posts about a SparkFun board with the same issues. I will try and get that MP3 file to you when I get home this evening.

Best, Mike.

User avatar
pasi
VLSI Staff
Posts: 1416
Joined: Thu 2010-07-15 16:04

Re: vs1053b plaing too fast

Post by pasi » Fri 2016-02-26 15:32

Yes, a floating xTEST pin could produce the symptoms by asserting DREQ when it should be low. (You will probably see a 6MHz signal from DREQ when it's floating.)
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook

hobbes88
User
Posts: 16
Joined: Mon 2015-05-11 0:58

Re: vs1053b plaing too fast

Post by hobbes88 » Sat 2016-02-27 2:35

Hi Pasi,

I E-mailed you an MP3 to test. I soldered pin 31 and 32 together. It did not seem to make a difference. So I guess the problem was not a floating Xtest pin.

Best, Mike.

hobbes88
User
Posts: 16
Joined: Mon 2015-05-11 0:58

Re: vs1053b plaing too fast

Post by hobbes88 » Sun 2016-02-28 1:17

Hi Pasi,

You were right on day one. The root cause of the issue was not respecting DREQ.

Just for laughs and a lesson of why people write real kernel device drivers rather than try and kludge things like me. I am on a Beagle Bone Black running Linux. ARM-hf, Robert C Nelson kernels.

The first problem was to try and capture DREQ I was using GPIO-keys. An interrupt driven driver for key presses. I though that this could keep up. However it does not and I ended up missing DREQ events. Some DREQ events did work, some did not. Hence the confusion, I was thinking hey I see DREQ's so that means it works. What we really should have said is we see "some" but not *ALL* the DREQ's. The GPIO-Keys implementation I think has some interrupts in there, but I am not sure if it is fully tuned for the TI SItara AM3358 and makes use of all the hardware registers, so could be sub optimal. I think it can capture interrupts well, however there is a cycle time before it is ready for another interrupt. That cycle time using GPIO-Keys was just too long. I read somewhere that the cycle time could be approx 100 milli seconds or so. Which matches with what I observed.

The next issue was also more subtle. If one looks at the Arduino examples, it says send the data, then check DREQ before you send some more data. I tried to do this and it failed. The reason is I was using a linux Write. A Write is simply a hand off of the data buffer to a kernel thread, and eventually some time down the road linux will get round to it. I was checking DREQ immediately, *before* the data had really left the Microprocessor core. Hence the return value on my DREQ check is High, ready for more data, But in fact there is a chunk of data "in transit" that has not hit the VS1053 yet.

So a very kludge hack, which probably will fail or cause glitches etc is:

1 Write a better DREQ pin check. I now use a /dev/mem mmap call to check the pin status. The pin is sampled with a 2 clock cycle delay in hardware. So that is 2 nano seconds on a Beagle Bone Black. Note you have to be Root or set SUID for this to work.

2 A dirty hack of an algo is then:

i) Send 32 byes of data using a buffered, multiple threaded, high latency Linux Write. So not the best way to go because we do not know when it is done.
ii) Wait about 2 milli seconds. (My SPI is 8Mhz, so this takes 32 micro seconds, and on top of that we add a Fudge/Saftely time). We have do do this to improve the chances that the 32 bytes we just sent has really arrived at the VS1053, So that the VS1053 can tell us if it is full of data or not by setting DREQ
iii) CHeck the DREQ pin via /dev/mmap. Wait untill it is high. Sort of test-sleep-wait. Then go back to i

Not the best solution, and bound to fail as the timings will change as the Linux kernel becomes under load. At least the tunes sound better though.

Best, Mike.

hobbes88
User
Posts: 16
Joined: Mon 2015-05-11 0:58

Re: vs1053b plaing too fast

Post by hobbes88 » Sun 2016-02-28 1:50

One final thing which may be of interest the resources required, so from TOP on linux is about 5% of the CPU, PID 2130 and PID 220

Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.3 us, 4.0 sy, 0.0 ni, 94.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 507624 total, 115128 used, 392496 free, 19292 buffers
KiB Swap: 0 total, 0 used, 0 free. 62916 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2130 root 20 0 45728 7420 4148 S 2.6 1.5 0:17.66 woofiemaincode
220 root 20 0 0 0 0 S 2.3 0.0 23:32.74 spi2

2135 ubuntu 20 0 4136 1932 1620 R 1.0 0.4 0:06.45 top
1070 ubuntu 20 0 9228 2760 2072 S 0.3 0.5 0:02.74 sshd
2037 root 20 0 0 0 0 S 0.3 0.0 0:02.32 kworker/0:0
1 root 20 0 3424 2600 1704 S 0.0 0.5 0:07.06 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:02.80 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kworker/u2:0
7 root rt 0 0 0 0 S 0.0 0.0 0:00.39 watchdog/0
8 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
11 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 perf
13 root 20 0 0 0 0 S 0.0 0.0 0:00.05 khungtaskd
14 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback

User avatar
Panu
VLSI Staff
Posts: 2423
Joined: Tue 2010-06-22 13:43

Re: vs1053b plaing too fast

Post by Panu » Mon 2016-02-29 10:54

Hi!

An interesting project, for sure. I hope you will share some of your source code when you get it working.

Just one remark:

Why not check the DREQ, then read how much space there is in the VS1053 stream buffer, and send that exact amount. And repeat until song played.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

Post Reply