Problem with VS1005G playback DSD

Discussion about writing software for VS1005 and the VSOS Operating System. Also posts about VS1005-related hardware design and device drivers should be posted here.
Post Reply
winwan
Senior User
Posts: 55
Joined: Fri 2014-07-04 15:51

Problem with VS1005G playback DSD

Post by winwan »

1-When playing DSD128, the speed slowed down by half. SD card speed is sufficient。
2-Another problem is that when playing DSD, FTOEQU cannot be loaded. There will be noise and abnormal sound
User avatar
Henrik
VLSI Staff
Posts: 1268
Joined: Tue 2010-06-22 14:10

Re: Problem with VS1005G playback DSD

Post by Henrik »

Hello!
winwan wrote: Tue 2021-12-14 13:00 1-When playing DSD128, the speed slowed down by half. SD card speed is sufficient。
I cannot confirm this. I tested with both PlayFile and PlayDir, and both played DSD128 properly. Below is an example with PlayFile:

Code: Select all

S:>cd d:dsd
D: SD/SD Card
D:DSD/>playfile Sweep064.dsf
Playing 'Sweep064.dsf'
[00:19]Decode finished.
D:DSD/>auoutput
stdaudioout:     0x1ff2, auodac::audioFile=0x0c43(3139)
  ->Identify():  0x2828, auodac::Identify returns "AUODAC"
  ->op:          0x1ffb, auodac::audioFileOps=0x0000(0)
    ->Ioctl():   0x26e0, auodac::AudioIoctl
    ->Write():   0x27de, auodac::AudioWrite
Sample rate:     44100
Bits per sample: 32
Buffer size:     4096 16-bit words (1024 32-bit stereo samples)
Buffer fill:     8 16-bit words (2 32-bit stereo samples)
Sample counter:  37488642
Underflows:      30722807
Volume:          +0.0 dB of maximum level
D:DSD/>playfile Sweep128.dsf
Playing 'Sweep128.dsf'
[00:19]Decode finished.
D:DSD/>auoutput
stdaudioout:     0x1ff2, auodac::audioFile=0x0c43(3139)
  ->Identify():  0x2828, auodac::Identify returns "AUODAC"
  ->op:          0x1ffb, auodac::audioFileOps=0x0000(0)
    ->Ioctl():   0x26e0, auodac::AudioIoctl
    ->Write():   0x27de, auodac::AudioWrite
Sample rate:     88200
Bits per sample: 32
Buffer size:     4096 16-bit words (1024 32-bit stereo samples)
Buffer fill:     8 16-bit words (2 32-bit stereo samples)
Sample counter:  39915471
Underflows:      31386188
Volume:          +0.0 dB of maximum level
D:DSD/>
As you can see, DSD64 sets playback sample rate to 44100 Hz, and DSD128 to 88200 Hz. This is correct.

Perhaps something in the headers causes the sample rate to be set incorrectly?

Can you send a very short audio sample that would show the issue? Even 1-2 seconds is fine. I don't know if our server accepts upload of DSD files, so compress to .zip first.
winwan wrote: Tue 2021-12-14 13:002-Another problem is that when playing DSD, FTOEQU cannot be loaded. There will be noise and abnormal sound
DSD requires lots of CPU power, and so does the Equalizer if many filters are used. Perhaps we are out of processing power? Let's check...

There are two useful methods to check how much CPU power you still have left, or how much over the limit you are.

Method 1: Using CpuFree to display the amound of free CPU:

Code: Select all

D:DSD/>setclock -l 98 86
D:DSD/>driver +cpufree -c100 100
D:DSD/>10.000s n=100: L  4.41u 81.61f; M  5.96u 80.05f; H 74.19u 11.83f; T 86.02 MHz
10.000s n=100: L  9.19u 76.83f; M  9.19u 76.82f; H  9.19u 76.82f; T 86.02 MHz
Above we set the system clock to 86.016 MHz, then start driver CpuFree, and command it to gather data in one hundred 100ms slices, so a total of 100x100ms = 10s. Then it reports how much free time there was.

Here we see that when doing nothing, the system uses on average 9.19 MIPS, and we have 76.82 MIPS free.

Code: Select all

D:DSD/>playfile Sweep128.dsf
Playing 'Sweep128.dsf'
[00:06]10.120s n=100: L  9.19u 76.83f; M 63.17u 22.85f; H 86.02u  0.00f; T 86.02 MHz
[00:17]10.002s n=100: L 82.92u  3.09f; M 83.08u  2.93f; H 83.21u  2.81f; T 86.02 MHz
[00:19]Decode finished.
When playing, we had on average 2.93 MIPS free and at lowest only 2.81 MIPS. This is very close to the limit where the system may start to skip. So, to give us more free CPU, I will remove the audio driver AUIADC:

Code: Select all

D:DSD/> 9.980s n=100: L  9.19u 76.82f; M 29.53u 56.49f; H 83.21u  2.81f; T 86.02 MHz
10.000s n=100: L  9.19u 76.83f; M  9.19u 76.82f; H  9.19u 76.82f; T 86.02 MHz
driver -auiadc
D:DSD/>10.000s n=100: L  4.41u 81.61f; M  5.77u 80.24f; H 24.78u 61.23f; T 86.02 MHz
10.000s n=100: L  4.41u 81.61f; M  4.41u 81.61f; H  4.41u 81.61f; T 86.02 MHz
Now the system requires 4.41 MIPS instead of 9.19 MIPS. Let's play the DSD128 file again:

Code: Select all

D:DSD/>playfile Sweep128.dsf
Playing 'Sweep128.dsf'
[00:08]10.002s n=100: L  4.41u 81.61f; M 70.37u 15.65f; H 86.02u  0.00f; T 86.02 MHz
[00:18]10.002s n=100: L 77.87u  8.15f; M 78.93u  7.08f; H 79.76u  6.25f; T 86.02 MHz
[00:19]Decode finished.
Now our worst case is 6.25 MIPS free, which is a safe margin. However, if you add the equalizer, you will run into zero free time and end up with problems.

Method 2: Using debug version of audiodec

From the VSOS Root Image package, copy solutions/audiodecdebug/audiodec/audiodec.dl3 to your S:SYS/. Now, when you play back audio, you will get a report once a second if there is not enough CPU time to play back seamlessly:

Code: Select all

S:>cd d:dsd
D: SD/SD Card
D:DSD/>setclock -l90 86
D:DSD/>playfile Sweep128.dsf
Playing 'Sweep128.dsf'
First read at 57.874s
First out  at 57.879s, 2661255 underflows
[00:00]Underflows at 58.878s = 2661369, grown 114
[00:19]Decode finished.
D:DSD/>
Above we can see that there is a very small glitch (114 samples) at the beginning of the file, but it is a small number and not repeated, so it is usually not a problem. However, if we lower the CPU speed to 61.44, we will get bad sound and a report every second:

Code: Select all

D:DSD/>setclock 60
D:DSD/>playfile Sweep128.dsf
Playing 'Sweep128.dsf'
First read at 191.880s
First out  at 191.888s, 12717372 underflows
Underflows at 192.884s = 12741836, grown 24464
[00:00]Underflows at 193.888s = 12766401, grown 24565
Underflows at 194.892s = 12790952, grown 24551
[00:02]Underflows at 195.896s = 12815504, grown 24552
Underflows at 196.900s = 12840057, grown 24553
[00:03]Underflows at 197.904s = 12864612, grown 24555
Underflows at 198.908s = 12889160, grown 24548
[00:05]Underflows at 199.912s = 12913713, grown 24553
Underflows at 200.916s = 12938268, grown 24555
[00:06]Underflows at 201.920s = 12962824, grown 24556
Underflows at 202.924s = 12987374, grown 24550
[00:07]Underflows at 203.928s = 13011929, grown 24555
Underflows at 204.932s = 13036480, grown 24551
[00:09]Underflows at 205.936s = 13061032, grown 24552
Underflows at 206.940s = 13085585, grown 24553
[00:10]Underflows at 207.944s = 13110140, grown 24555
Underflows at 208.948s = 13134688, grown 24548
[00:12]Underflows at 209.952s = 13159241, grown 24553
Underflows at 210.956s = 13183796, grown 24555
[00:13]Underflows at 211.960s = 13208352, grown 24556
Underflows at 212.964s = 13232902, grown 24550
[00:15]Underflows at 213.968s = 13257457, grown 24555
Underflows at 214.972s = 13282008, grown 24551
[00:16]Underflows at 215.976s = 13306560, grown 24552
Underflows at 216.980s = 13331113, grown 24553
[00:18]Underflows at 217.984s = 13355668, grown 24555
Underflows at 218.988s = 13380216, grown 24548
[00:19]Decode finished.
D:DSD/>
With CpuFree and/or audiodecdebug, you may get a good understanding on how much you still can add functions.

Kind regards,
- Henrik
Good signatures never die. They just fade away.
winwan
Senior User
Posts: 55
Joined: Fri 2014-07-04 15:51

Re: Problem with VS1005G playback DSD

Post by winwan »

I sent out two files. You can test them
Music.rar
(39.81 MiB) Downloaded 37 times
User avatar
Henrik
VLSI Staff
Posts: 1268
Joined: Tue 2010-06-22 14:10

Re: Problem with VS1005G playback DSD

Post by Henrik »

Hello!
winwan wrote: Tue 2021-12-14 16:44 I sent out two files. You can test them
Music.rar
Thank you for the files! It is always useful to get more examples of the less common file formats.

I used the debug version of audiodec and got the following results.

check_dsd64.dff played fine:

Code: Select all

D:DSD/>playfile check_dsd64.dff
Playing 'check_dsd64.dff'
First read at 126.399s
First out  at 126.402s, 3157890 underflows
[00:00]Underflows at 127.405s = 3157899, grown 9
[00:28]Decode finished.
D:DSD/>auoutput
stdaudioout:     0x1ff2, auodac::audioFile=0x0c43(3139)
  ->Identify():  0x2828, auodac::Identify returns "AUODAC"
  ->op:          0x1ffb, auodac::audioFileOps=0x0000(0)
    ->Ioctl():   0x26e0, auodac::AudioIoctl
    ->Write():   0x27de, auodac::AudioWrite
Sample rate:     44100
Bits per sample: 32
Buffer size:     4096 16-bit words (1024 32-bit stereo samples)
Buffer fill:     8 16-bit words (2 32-bit stereo samples)
Sample counter:  11864885
Underflows:      4860821
Volume:          +0.0 dB of maximum level
D:DSD/>
Sample rate is 44100 Hz, so it is good.

check_dsd128.dff didn't have enough CPU. But when I set the clock to 86 MHz and removed audio input driver AUIADC.DL3, it played correctly:

Code: Select all

D:DSD/>setclock -l92 86
D:DSD/>driver -auiadc
D:DSD/>playfile check_dsd128.dff
Playing 'check_dsd128.dff'
First read at 338.108s
First out  at 338.111s, 11216842 underflows
[00:00]Underflows at 339.110s = 11216969, grown 127
[00:28]Decode finished.
D:DSD/>auoutput
stdaudioout:     0x1ff2, auodac::audioFile=0x0c43(3139)
  ->Identify():  0x2828, auodac::Identify returns "AUODAC"
  ->op:          0x1ffb, auodac::audioFileOps=0x0000(0)
    ->Ioctl():   0x26e0, auodac::AudioIoctl
    ->Write():   0x27de, auodac::AudioWrite
Sample rate:     88200
Bits per sample: 32
Buffer size:     4096 16-bit words (1024 32-bit stereo samples)
Buffer fill:     8 16-bit words (2 32-bit stereo samples)
Sample counter:  21033506
Underflows:      11474491
Volume:          +0.0 dB of maximum level
D:DSD/>
Sample rate is 88200 Hz, which is again correct.

Do you get the same or different results with the same commands?

Kind regards,
- Henrik
Good signatures never die. They just fade away.
winwan
Senior User
Posts: 55
Joined: Fri 2014-07-04 15:51

Re: Problem with VS1005G playback DSD

Post by winwan »

I reset the clock according to your operation, and the DSD128 can play normally. I also tried the DSD256, and it can play normally. Now it has been found that PLAYDIRP has a fatal flaw, I will send the data later.
Thanks for your support!! :D :D
winwan
Senior User
Posts: 55
Joined: Fri 2014-07-04 15:51

Re: Problem with VS1005G playback DSD

Post by winwan »

CPU monitoring:PLAY DSD256,DRIVER +FTOEQU
[00:04]10.005s n=100: L 4.50u 87.66f; M 66.52u 25.64f; H 92.16u 0.00f; T 92.16 MHz
Running these two threads at the same time is not fast enough. I want to know if adding SDRAM can solve this problem.
This is caused by insufficient cache or CPU speed?? :?: :?:
User avatar
Henrik
VLSI Staff
Posts: 1268
Joined: Tue 2010-06-22 14:10

Re: Problem with VS1005G playback DSD

Post by Henrik »

Hello winwan!
winwan wrote: Wed 2021-12-15 4:17 CPU monitoring:PLAY DSD256,DRIVER +FTOEQU
[00:04]10.005s n=100: L 4.50u 87.66f; M 66.52u 25.64f; H 92.16u 0.00f; T 92.16 MHz
Running these two threads at the same time is not fast enough. I want to know if adding SDRAM can solve this problem.
This is caused by insufficient cache or CPU speed?? :?: :?:
The issue is CPU speed, so unfortunately in this case I cannot think of an easy way around it. The not-easy way would be to use two VS1005's, connected with e.g. I2S. However, using 2 VS1005's of course drives the cost up and makes maintenance and programming of the system more difficult.

Kind regards,
- Henrik
Good signatures never die. They just fade away.
winwan
Senior User
Posts: 55
Joined: Fri 2014-07-04 15:51

Re: Problem with VS1005G playback DSD

Post by winwan »

hi Henrik:
I have understood this problem about DSD, thank you very much for your help!!
Post Reply