Need help to understand an issue with Wave/play object

#1

Hey!

I am having some issues with the wave/play object. I am trying to have 2 of them playing at the same time, sending different sequences to both of them, like on the picture. But the problem is as soon as I connect the sequencer to the SECOND wave/play object, the sequence from the SECOND one, "leaks" into the FIRST wave/play object, creating unwanted clicks everytime the SECOND wave/play is triggered. When I remove the cable from sequencer to SECOND wave/play the clicking stops again.

Right now I cant achieve a goal of making a drum machine with the wave players. I am a bit befabled by this, as I think I have seen others in here use 5-6 of them in patches. WOnder if they have same issues and just didnt notice?

I have tested using two seperate sequencers, instead of one with 4, with no luck. I have tried embedding the waveplayer, with no luck. Now I am out of ideas. Anyone have got an idea on how to solve this? Any help appreciated :wink:

Another issue is that everytime the patch is made "unlive" Axoloti disconnects. Small issue, but I thought I might mention it while I was at it.

Patch & picture:

DrumE 2016 3 1 find ud af det 1.axp (16.0 KB)

wplay.png1035x665 68.9 KB

PS. I also tested the demo patch "sample drum machine.axp" with same result as described above. It is like whatever is feed to one wave/play is leaked into the others creating clicks.

Could it be related to sd card? I need to do the Sd bench mark test i guess..

I am on Axoloti 1.0.11 and Osx 10.10.5

#2

Sd benchmark test. Which number should I look at?

Starting sdcard benchmark. Wait...
Done starting patch
Start locking
Done locking
Open OK...
lseek1 OK...
lseek2 OK...
lseek err 17

lseek err 17

nstreams = 1,
NBUFFERS = 128,
BUFSIZE = 8192

open : 1445 ms

write BW : 712 kB/s

close : 7 ms

open : 137 ms

read BW : 4832 kB/s

Open OK...
lseek1 OK...
lseek2 OK...
lseek err 17

Open OK...
lseek1 OK...
lseek2 OK...
lseek3 OK...
lseek err 17

nstreams = 2,
NBUFFERS = 128,
BUFSIZE = 8192

open : 2428 ms

write BW : 708 kB/s

close : 114 ms

open : 60 ms

read BW : 4529 kB/s

Open OK...
lseek1 OK...
lseek2 OK...
lseek err 17

lseek err 17

nstreams = 1,
NBUFFERS = 128,
BUFSIZE = 4096

open : 1435 ms

write BW : 1050 kB/s

close : 7 ms

open : 137 ms

read BW : 3912 kB/s

Open OK...
lseek1 OK...
lseek2 OK...
lseek err 17

Open OK...
lseek1 OK...
lseek2 OK...
lseek3 OK...
lseek err 17

nstreams = 2,
NBUFFERS = 128,
BUFSIZE = 4096

open : 2428 ms

write BW : 963 kB/s

close : 112 ms

open : 60 ms

read BW : 3518 kB/s

Open OK...
lseek1 OK...
lseek2 OK...
lseek err 17

lseek err 17

nstreams = 1,
NBUFFERS = 128,
BUFSIZE = 2048

open : 1433 ms

write BW : 490 kB/s

close : 7 ms

open : 137 ms

read BW : 1941 kB/s

Open OK...
lseek1 OK...
lseek2 OK...
lseek err 17

Open OK...
lseek1 OK...
lseek2 OK...
lseek3 OK...
lseek err 17

nstreams = 2,
NBUFFERS = 128,
BUFSIZE = 2048

open : 2443 ms

write BW : 517 kB/s

close : 113 ms

open : 60 ms

read BW : 1765 kB/s

Open OK...
lseek1 OK...
lseek2 OK...
lseek err 17

lseek err 17

nstreams = 1,
NBUFFERS = 128,
BUFSIZE = 1024

open : 1443 ms

write BW : 251 kB/s

close : 7 ms

open : 136 ms

read BW : 985 kB/s

Open OK...
lseek1 OK...
lseek2 OK...
lseek err 17

Open OK...
lseek1 OK...
lseek2 OK...
lseek3 OK...
lseek err 17

nstreams = 2,
NBUFFERS = 128,
BUFSIZE = 1024

open : 2428 ms

write BW : 269 kB/s

close : 111 ms

open : 60 ms

read BW : 885 kB/s

SDCard benchmark finished.

#3

The last reported pair are the figures of note .. mine for comparison

May I ask .. is there a set place to locate / store wave files for those objects ?

Any folder / in the patch folder / a set location ?

#4

that looks suspicious , i don't get any lseek errors when I run the benchmark

e.g.

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 : 431 ms
write BW : 1892 kB/s
close : 6 ms
open : 31 ms
read BW : 3628 kB/s

if you used something with 'choose' then the file is uploaded automatically.
if you use a filename input, then by default its in the 'patch directory' (created when you upload a patch), but you can override using /mydirectory/x.raw

#5 
   FR_NOT_ENOUGH_CORE,     /* (17) LFN working buffer could not be allocated */

try formatting the SDCard, Ive a suspicion it may have too many files on it.

(from a quick glance at the ff.c code, but @johannes may know of other reasons)

#6

when i tried there was no way for me to point to the files on the SDCard

what's this .raw format business about, that's what i'd be familiar with from say a decent camera

there's no help file for those objects so i'm a little in the dark in terms of syntax for pointing to sound file, i'll get there by intuition, trial and error i suppose, but it was one of those new user mini-barriers i stumbled upon

where might i find the info pertaining to this 8mb limit (and similar info) besides finding out by getting to a point where i'm forced to search ? - i'm also struggling for an explanation as to why my modest 5 file 13mb-total upload was very slow (is there conversion ? better check my editor for .raw !)

#7

Thanks @avantronica. Seems like my Sd-card is sh***t. It has been formatted with Axolotis own formatter.

On my Sd-card I have a folder called "wav". If I want to use samples inside that folder you can call them up with:

/wav/filename.raw

NB. Filenames MUST be MAXIMUM 8 characters long.

But in my example, I use the string/index objects. All the files end with 001, 002, 003, so I can switch between them while the patch is live. That is the set up that you see it in my patch.

You can also use the waveplayer with "choose". With that objects you can select any file on harddisc and Axoloti will upload it to the patch folder. I am not into this method. I prefer not to use the patch folder idea cause imo it makes Axoloti less flexible and will fill sd-card very quickly with multiple copies of same files.. Bu that is just my opinion.

#8

Dont even know what iseek errors are.

It do have A LOT of files on it. Argh formatting it is a bit complicated, cause of alot of files. is there a limit to how many files Axoloti accepts? But if you think it'll help Ill make a backup copy of it and format it. But that is a big task.. Maybe i just need to clean it up a bit.

#9

Push CHOOSE........... and you can set the filepath......[quote="avantronica,

I am going to refer to the E-book I suggested you yesterday. In that book, there is a description on how to prepare files. Also if you search the forum you will find many answers for that question.

#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