Load sample from Sd to waveplayer crashes

#25

not really... its very predictable behaviour

i can run the 8 track patch 20 times in a row and its absolutely fine.
but if I load another patch, run it
then load the 8 track patch, it will crash.
but, try to run it again a few times ... and it will start working every time again.

what Ive also noticed is, if I run the LFO slow initially so its done one trigger of each player sequentially,
then after that I can turn up the LFO to ludicrous rate and its works fine.

as stated previously, it the kind of initialisations phase that looks like its got a bug.
(Id guess perhaps that initial buffer is possibly not ready or something like that... possibly because IO has been done to load another sample... whats interesting is that after the initial read, its seems to be ok)

#26

I get exactly this russian roulette behaviour, with 8 play fn stereo objects triggered by pads on my Nanopad 2.
Sometimes everything works perfect and all samples play fine, quite often the axo hangs and crashes.
Newly formatted SD card, and I mounted the card in OSX to upload all the samples. I reconnect, press the first pad and boom, crash again.
The player triggered by this pad was earlier working fine, so it's not the sound itself.

After rebooting, this shows up:

Authentic Axoloti Core
Axoloti says: USB Device Attached
Axoloti says: PID: 116h
Axoloti says: VID: 944h
Axoloti says: Address (#1) assigned.
Axoloti says: Manufacturer : KORG INC.
Axoloti says: Product : nanoPAD2
Axoloti says: Serial Number : N/A
Axoloti says: Enumeration done.
Axoloti says: This device has only 1 configuration.
Axoloti says: Default configuration set.
Axoloti says: Switching to Interface (#0)
Axoloti says: Class : 1h
Axoloti says: SubClass : 3h
Axoloti says: Protocol : 0h
Axoloti says: USB Host Output size requests : 40
Axoloti says: USB Host Input size requests : 40
Axoloti says: USB Host Output connected to 0 : 2
Axoloti says: USB Host Input connected to 0 : 81
Axoloti says: MID class started.
Axoloti says: exception: soft watchdog
Axoloti says: pc=0x80063E2
Axoloti says: psr=0x61000000
Axoloti says: lr=0x800730D
Axoloti says: r12=0x8007381
Axoloti says: cfsr=0x8200
Axoloti says: bfar=0xA31340C0
Firmware version: 1.0.0.1, crc=0xC7D2E87E, entrypoint=0x20011000

#27

ok, we have to be clear here... and separate the UI from the board... how do you know the board has hung/crash?

are you able to just reconnect to the board from the UI without a power cycle?

have you tried setting pos to zero (as above) on the player ? (this helped me)

does the patch crash after you having been playing with it for a bit? or only during the first few seconds.
(my experience is, it crashes the first time it attempts to play a sample... but after that it appears to be stable)

note: this is why the sequencer example was good, as it plays all the samples quickly...
i suspect, if you are playing with a PAD, it might crash the first time you hit one particular sample, which could of course be a few minutes since it went live.

also if its crashing, it may be its not freeing resources correctly... so power cycling would probably be necessary.
(again it seemed quite stable after power cycle, but if I load other patches first then it crashes)

anyway, Ive forwarded my patch/wav to johannes, along with my findings so far... so I think we have at least one hand on the bug smile

#28

OK, the UI crashes then.
Uploading to the SD card makes the board crash as soon as I press the pad, same behaviour after uploading to flash.
After reconnecting this is the log which I have never seen before:

Rx paramchange patch null4 57 671 680
Rx paramchange patch null5 -75 497 472
Rx paramchange patch null6 0
Rx paramchange patch null7 134 217 728
Rx paramchange patch null8 130 023 424
Rx paramchange patch null13 56 623 104
Rx paramchange patch null14 -75 497 472
Rx paramchange patch null15 0
Rx paramchange patch null24 97 517 568
Rx paramchange patch null25 134 217 728
Rx paramchange patch null26 71 303 168
Rx paramchange patch null27 134 217 728
Rx paramchange patch null28 134 217 728
Rx paramchange patch null29 92 274 688
Rx paramchange patch null30 12 582 912
Rx paramchange patch null31 115 343 360
Rx paramchange patch null32 106 954 752
Rx paramchange patch null33 133 169 152
Rx paramchange patch null34 10 485 760
Rx paramchange patch null35 -48 234 496
Rx paramchange patch null36 -134 217 728
Rx paramchange patch null37 -134 217 728
Rx paramchange patch null38 134 217 728
Rx paramchange patch null39 60 817 408
Rx paramchange patch null40 10 485 759
Rx paramchange patch null41 -48 234 495
Firmware version: 1.0.0.1, crc=0xC7D2E87E, entrypoint=0x20011000

Reconnecting again without power cycle is no problem, but the UI crashes instantly after pressing a certain pad (some of the pads work, one triggers an oscillator and this seems to work all the time)
It crashes as soon as I trigger a certain sound that doesn't work. These seem to change from time to time, although I'm not sure when..
The other day I ran a sequencer playing a bunch of sounds non stop for 30 minutes, today it's a lot of trouble..
All samples are set to zero offset with a constant of 0 connected to the pos input. However, this was not needed when running the sequencer.

Checking out the SD card reveals a load of files that weren't there before

Skärmavbild 2015-09-12 kl. 23.07.03.png709x665 79.3 KB
, there is no start.bin on my memory card according to Finder

#29

I suspect most of those files have been added by Mac OS X,
annoyingly whenever you mount a filesystem on the Mac, it will add spotlight and trash files on them
(they wont cause any harm, just use up space unnecessarily and make browsing more awkward)
deleting things on Finder is also not-advisable it tends to keep them, until you empty trash with the device connected.

its why I tend not to transfer with a card reader on the mac... I really wish Apple would allow you to turn this off for removable filesystems!

the zero pos as i said, I think is also due to initialisation issue, if memory happens to contains zero, its not needed, but then next time if memory has non-zero in, it is needed... hence the random element.

it sounds like your seeing the same behaviour as I am ...it fails on first sample play, or works...
( I similarly found, when it failed, it tended to fail on the same sample ... again probably just due to memory layout)

its good that we are seeing the same/similar behaviour, hopefully rules out hardware (including cards) and more down to a timing/initialisation issue.
thanks for the info
Mark

#30

I think I have found and solved the cause of trouble with the waveplayer... Was closing an invalid filehandle...
The fix is in the git repository already, still need a bit more testing before release.
Thanks for all the comments, really helpful!

#31

Unconnected inlets are assigned to zero. I don't believe this was related.

The result of closing the invalid filehandle(s) did depend on previous memory content, hence the very inconsistent behavior. Repeated loading of the same patch was consistent for this reason...

#32

Its looking good... just tested with 12 players, even triggering with an at 3khz player was stable smile
(at about 12 players you run out of rate, I suspect due to the buffer allocation on the player thread?)

EDIT @johannes perhaps we should post a copy of the 'fixed' objects here, for widespread testing? or make a new release?
I think id prefer that later, as there are a few things already in the dev version that would be good to get 'out in the wild' smile

EDIT2: for those desperate to test...
you can download from github here:
https://github.com/axoloti/axoloti/tree/master/objects/wave

Important note: they are development only, so you can report issues, but don't be upset if they have other issues!
they are for testing ONLY.

my recommendation to use : backup your original versions first then overwrite.

if they don't appear to help (which they do for me ) then double check that the new versions are being picked up BEFORE you report issues here.

Axoloti Disconnects when have more than 2 SDcard read objects
#33

Went with the "desperate to test" (so helping out)…

Reliable, smooth and accurate playing, even with exact same file (using only one file - multiple players)
Great work !! wink relieved

#34

Played with wave/play stereo and did not experienced any problem yet

#35

thanks guys... can you try with different samples (as i tried with 1 wav as well)

'desperate' was the wrong word smile perhaps 'eager' would have been better ... its obviously great to have people help test things out.

#36

Wow Johannes, it seems to be playing very nicely now!
The only thing that would definitely crash my patch Every time was to upload to SD card as startup and now it finally doesn't crash! Well done! ^____^

#37

wave/play fn (mono) seems to play file with wrong sample rate. It plays it slower.

#38

The current wave/play objects assume the file format and samplerate. Raw 48kHz 16 bit, mono or stereo. If it is a .wav file, it will "just play" the .wav header too, resulting in a brief click at the start. It will play any file, jpg, avi, xls, whatever, but simply as raw data.

How to load audio files / Create Tables
#39

Can u maybe help me out with exchange im on win7 what do i have to :smiley: i can get it to run sometimes as it is now but its not usable at all takes to much time to get it running.. so would love to test the "beta" of the updated version

#40

format the SD with the Axoloti. Be sure the files are 48kHz / 16bit, convert them in .raw format, everything should be fine

#41

File format is fine... sd card formatted its not that i not have done those things... im not that noob... and have tried the obvius things before writing here....

#42

I'm getting those errors when trying to use a 16/48khz file. Should this be fixed in 1.08? I'm formatting from audacity choosing raw and 'signed 16 bit' - I've tried with raw and wav extensions but either way I get the following error:

Control transfer failed: -9
Ping: WaitSync Timeout, disconnecting now
Disconnect request
Control transfer failed: -4

Card was formatted by axoloti and gets the following benchmarks:

Axoloti says: open : 611 ms
Axoloti says: write BW : 460 kB/s
Axoloti says: close : 6 ms
Axoloti says: open : 24 ms
Axoloti says: read BW : 1956 kB/s

#43

File format is not suspect, any file - like a powerpoint presentation - would be played, likely only resulting in noise or glitchy sounds, but not a crash. If the samplerate 'd be off, it would still play but transposed. If it'd be a 32 bit raw file, it'd sound distorted and at half speed. Play a .wav file, and you will get a click resulting from the file header played back.

1.0.8 is improved in reporting file access errors, and also added support for long filenames. 1.0.6 is limited to 8 character filenames with a 3 character extension.

#44

Hmm.. well I'm using 1.08 so I wonder what the problem is. I'm trying to run the demo patch mentioned earlier in this thread.