Need help to understand an issue with Wave/play object


#10

This indicates significant disk fragmentation on the sdcard.

The file created for benchmarking had over 64 fragments for a single file. The location of fragments is mapped to a bit of memory, but the given memory is too small. This error still allows to continue processing files, but can't expect good performance at this level of disk fragmentation.
I suggest to defrag the card, not sure there is an utility in OSX for this. Otherwise, copy all files to your computer, then format the card, and put your files back on the card. I suggest using a sdcard reader for this, would take a long time using card reader mode.


#11

Thanks for the tip. Ill remove everything form the card and format it.

Hm... Can you tell me how to format in 1.0.11? I remember it is a bit different than older versions, but not sure how to do it.

@ johannes, you dont think I need to worry about the amount of files on the sd-card? (hoping not)


#12

formatting info

I believe the total file count does not really matter, but it is best to keep the number of files in a single directory relatively small.


#13

Hm, now I just tried to do the benchmark test on another sd-card. It have taken several minuts now. Is that normal?

Look really weird doesnt it? Test made on same Axoloti synth but different sd-card.

Starting sdcard benchmark. Wait...
Open OK...
Done starting patch
Start locking
Done locking
lseek1 OK...
lseek2 OK...
lseek3 OK...
nstreams = 1,
NBUFFERS = 128,
BUFSIZE = 8192

open : 295 ms

write BW : 28 kB/s

close : 1 ms

open : 0 ms

read BW : 0 kB/s

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

open : 598 ms

write BW : 28 kB/s

close : 6 ms

open : 0 ms

read BW : 0 kB/s

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

open : 301 ms

write BW : 14 kB/s

close : 1 ms

open : 0 ms

read BW : 0 kB/s

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

open : 598 ms

write BW : 14 kB/s

close : 6 ms

open : 0 ms

read BW : 0 kB/s

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

open : 301 ms

write BW : 7 kB/s

close : 0 ms

open : 0 ms

read BW : 262144 kB/s

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

open : 598 ms

write BW : 7 kB/s

close : 6 ms

open : 0 ms

read BW : 0 kB/s

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

open : 301 ms

write BW : 3 kB/s

close : 0 ms

open : 0 ms

read BW : 131072 kB/s

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

open : 598 ms

write BW : 3 kB/s

close : 6 ms

open : 0 ms

read BW : 0 kB/s

SDCard benchmark finished.


#14

Anyway, I have formatted the first card and before i copy anything to it, I did another benchmark test. This time it looked like this:

Starting sdcard benchmark. Wait...
Open OK...
Done starting patch
Start locking
Done locking
lseek1 OK...
lseek2 OK...
lseek3 OK...
nstreams = 1,
NBUFFERS = 128,
BUFSIZE = 8192

open : 453 ms

write BW : 2016 kB/s

close : 6 ms

open : 130 ms

read BW : 5761 kB/s

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

open : 1012 ms

write BW : 726 kB/s

close : 110 ms

open : 53 ms

read BW : 5548 kB/s

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

open : 580 ms

write BW : 902 kB/s

close : 6 ms

open : 129 ms

read BW : 4128 kB/s

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

open : 1169 ms

write BW : 918 kB/s

close : 111 ms

open : 53 ms

read BW : 4032 kB/s

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

open : 578 ms

write BW : 544 kB/s

close : 6 ms

open : 28 ms

read BW : 2016 kB/s

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

open : 1169 ms

write BW : 524 kB/s

close : 23 ms

open : 53 ms

read BW : 1993 kB/s

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

open : 580 ms

write BW : 244 kB/s

close : 6 ms

open : 28 ms

read BW : 1024 kB/s

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

open : 1178 ms

write BW : 264 kB/s

close : 9 ms

open : 54 ms

read BW : 1020 kB/s

SDCard benchmark finished.

Is that good or bad? I guess no errors, so that is a good thing :slight_smile:


#15

The second card, looks really weird, probably a broken card, worn out, or suffering bad sectors or something. Avoid using it for any data in any device you want to see again in the future.

The original card, well, the lseek err 17 is gone, right?

To compare your card's performance to other cards, there's a whole thread already.


#16

Hm... Both cards were bought from new and only used for Axoloti. Anyway, I think I need new ones then. Both of them are really slow, compared to others form the test. But that is a good thing, getting new cards, will probably give me better performance :slight_smile:

Yes errors are gone. Just about finishing copying files back to card. Will keep you updated. Thanks :wink:


#17

Ok, so just finished copying everything and did the benchmark test again. Not very fast, but no errors :slight_smile: :

write BW : 269 kB/s
read BW : 897 kB/s

And next I opened the same patch as before. I still get the clicking as described in the first post in this thread. And Axoloti also still disconnects when I make the patch unlive.

Maybe it is related to the slow sd-card then? Will get a new one soon and test that. If you guys have got other suggestions I am happy to try them out :slight_smile:

Looking at a new card right now. Does it matter if the card is:
UHS-1 class 10
or
UHS-3 (for 4k videos it says)

I know some decription is presented in this thread:

But I just didnt really see any final conclusion on what would be the ideal. It would be really great to get a fast one this time :slight_smile:

Thanks!


#18

what's the marked spec on your card ? and I can try eventually to try the test on my modestly mid>high spec card to see if it's relevant - i'd imagine not, but what do I know

270/900 compared or 330/1700 for my 533x(80Mb/s) Class10 card


#19

Specs are:
Nashua Micro sd-hc
Class 4
8 Gigs

write BW : 269 kB/s
read BW : 897 kB/s

From looking at the benchmark thread, I think I am going to get a UHS-class10 card. Those cards seem to have a pretty consistent high reading bandwidth, like 1500 and up. 2 times what I have now.

Do you see any difference in performance between those 2 cards?


#20

I was quoting your stats against my stats for my sole SanDisk as listed in that thread, I bought that one in the UK as it was a fair low price for a known brand and a reputable dealer - anything from eBay could potentially be counterfeit

my hunch is this is all a bit academic - a device like the OctaTrack can stream from its CF card with a more modestly rated card e.g. 266x and quite happily stream 8 24/44.1 files simultaneously without choking - maybe CF is a bit more adapted to this need


#21

Ahh, that is what you meant. Sorry, hehe :slight_smile:

I think Ill just get a new one like this one. Is less than 10 euro, in danish kroner 59 kr.

http://www.pc-lager.dk/vare-oversigt.php?varenummer=989943585


#22

I just made a Mellotron-style patch with a sample per key and I am getting clicks like you described. Did a faster card fix it for you?


#23

...and to answer my own question, no that didn’t fix things. I just got the fastest card I could find. It might have helped a bit, I’m not sure, but the clicks are still there.


#24

@Abhoth

I am wondering which type of files you are using? .wav or .raw?


#25

I’m using .raw files. It is not the new file that starts playing that creates the click, btw. (I thought so at first). The click is in the audio stream that is already playing. I’m guessing what is happening is the streaming gets temporarily interrupted for a short while whenever a new wave/play starts playing.


#26

Cool just wanted to rule out the fileheader issue, cause it wasnt mentioned.

But sorry, I havent dug more into this, I use these object very rarely.


#27

After quite a bit of digging I now have a click-free 8 voice Mellotron. Yay! In the end, lowering the thread priority was all that was needed.


#28

Hey @Abhoth, I'm also trying to make a mellotron like instrument. Would you mind sharing your patch? Thanks!


#29

The finished version is in the community library. The tough part was the pitch control. I don't remember the details, but I used two sets of buffers, one that reads from the SD card, and one where the stream is "resampled" at the new pitch. A very fast SD Card is required to make it work reliably.

If you don't want the pitch control, you could just use the Wave/play object and edit the thread priority. From memory, what cause a click is that the seek time when finding the start of a file on the sd card is too long, thus creating an audible click in the audio stream. When I reduced the thread priority, starting playing might take slightly longer, but it doesn't disrupt the audio anymore.