Playback problem with more than 4 .wav files


#1

I'm doing some tests with .wav files, here's a brief report with some issues in it:

  1. using up to 8 stereo .wav format 48khz/16bit files, 5 character uppercase name, 30 seconds duration
  2. using the stereo mixer abstraction
  3. SD card formatted with Axoloti

the sound start clipping immediately like if the CPU is over when it's just at 16%
If I start to delete players I can find the patch working with up to 4 files with the specs written above,

Any idea?


#2

Could you post the results from the sdbenchmark object? Streaming playback performance depends on sdcard performance. There are huge differences between sdcards and unfortunatly the advertised speed rating is not representative.

The DSP load indicator does not take the sdcard reading/buffering process into account.

For short samples - where streaming is not needed - it is better to load them into tables in sdram rather than streaming them from sdcard. Admittedly this is underdocumented.


#3

Thanks Johannes,

this is my benchmark

Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: nstreams = 1,
Axoloti says: NBUFFERS = 128,
Axoloti says: BUFSIZE = 8192

Axoloti says: open : 399 ms

Axoloti says: write BW : 819 kB/s

Axoloti says: close : 7 ms

Axoloti says: open : 18 ms

Axoloti says: read BW : 4228 kB/s

Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: nstreams = 2,
Axoloti says: NBUFFERS = 128,
Axoloti says: BUFSIZE = 8192

Axoloti says: open : 933 ms

Axoloti says: write BW : 814 kB/s

Axoloti says: close : 11 ms

Axoloti says: open : 34 ms

Axoloti says: read BW : 3847 kB/s

Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: nstreams = 1,
Axoloti says: NBUFFERS = 128,
Axoloti says: BUFSIZE = 4096

Axoloti says: open : 1294 ms

Axoloti says: write BW : 1368 kB/s

Axoloti says: close : 7 ms

Axoloti says: open : 19 ms

Axoloti says: read BW : 2912 kB/s

Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: nstreams = 2,
Axoloti says: NBUFFERS = 128,
Axoloti says: BUFSIZE = 4096

Axoloti says: open : 1086 ms

Axoloti says: write BW : 1100 kB/s

Axoloti says: close : 15 ms

Axoloti says: open : 34 ms

Axoloti says: read BW : 2461 kB/s

Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: nstreams = 1,
Axoloti says: NBUFFERS = 128,
Axoloti says: BUFSIZE = 2048

Axoloti says: open : 568 ms

Axoloti says: write BW : 777 kB/s

Axoloti says: close : 7 ms

Axoloti says: open : 18 ms

Axoloti says: read BW : 1542 kB/s

Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: nstreams = 2,
Axoloti says: NBUFFERS = 128,
Axoloti says: BUFSIZE = 2048

Axoloti says: open : 1088 ms

Axoloti says: write BW : 536 kB/s

Axoloti says: close : 11 ms

Axoloti says: open : 34 ms

Axoloti says: read BW : 1291 kB/s

Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: nstreams = 1,
Axoloti says: NBUFFERS = 128,
Axoloti says: BUFSIZE = 1024

Axoloti says: open : 566 ms

Axoloti says: write BW : 121 kB/s

Axoloti says: close : 7 ms

Axoloti says: open : 19 ms

Axoloti says: read BW : 784 kB/s

Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: Open OK...
Axoloti says: lseek1 OK...
Axoloti says: lseek2 OK...
Axoloti says: lseek3 OK...
Axoloti says: nstreams = 2,
Axoloti says: NBUFFERS = 128,
Axoloti says: BUFSIZE = 1024

Axoloti says: open : 1095 ms

Axoloti says: write BW : 272 kB/s

Axoloti says: close : 11 ms

Axoloti says: open : 34 ms

Axoloti says: read BW : 653 kB/s

Axoloti says: SDCard benchmark finished.


#4

Using tables could be a solution but at the same time it's not very quick to read stereo files...
I think that some wrapper similar to the "wave play fn stereo" to read from RAM would be very nice


#5

One stereo stream at 48kHz/16bit needs 192kB/s

I am already surprised you get 4 simultaneous streams with your card. The measured bandwidth is average benchmark which hides the (more relevant) worst case buffer read time.

I have seen cards with much better performance. But even with a good card I think 8 streams is probably the maximum.

Yes. This is what makes it a bit complicated: ideally the size of the sample should be known when the patch is compiled, so that the a chunk of memory can be reserved of the right size. But the patcher does not know what is on the sdcard. Ideally, the wave file referenced in the patch should be in the same directory on the computer as the patch, and automatically uploaded to sdcard when it is missing there.

Also, stereo tables do not exist. I'm not sure adding stereo tables is a good idea. I don't think there are stereo tables in Pd or Max. If stereo tables are added, there is also reason to add 3-channel (LCR), 4-channel (quadrophonic), 6-channel (5.1 surround), 8-channel tables. If they're separate families of objects, that explodes the number of objects.
While adding "n-channel" tables will make common application scenarios more complicated than needed.


SDCard performance discussion
#6

2 posts were merged into an existing topic: SDCard performance discussion


#7

1024 bytes is the default, for both stereo and mono.
Larger buffers would increase throughput, but also latency.
Streaming sdcard playback was developed before sdram was there. There are tricks that could be worked out, like caching the sdcard FAT table in sdram.
But I think it is best to focus efforts on an easy path to load waves in sdram tables. 8MB of random-access samples + a few streaming samples covers a lot of uses.

Tables with interleaved stereo data would be quite a bit more efficient than dual mono tables.


#8

can't figure out if related but working on Windows 8 gives me more stability than working on Os10.10


#9

my problem persists but can't figure out why.

I have two patches both with 4 stereo files at 48kHz/16bit 10 seconds duration each.
The first patch uses fn stereo objects, the second one uses stereo objects + MIDI controller dyanimc string for file selection.
While the first patch run without problems, the second one compile one time every 10...it's a bit frustrating because it works very randomly...also the file selection, when the patch compile is very fluid. Can't really figure out why.
It could depends on some default settings that sends unwanted values?