WvOut direct to disk or to buffer?

[Gear Addict]

Worked on an audio/sensor recording application in Chuck a while back, and had to unfortunately abort using it because there seemed to be a known issue where randomly, samples would drop/be lost while recording (trying to record synchronous audio + sensor data to .wav files).

Recently, I was playing around with Minim in Processing and experienced similar issues when recording directly to disk, although, it seemed to work fine when instead, I specified to record the stream to a buffer, and then write to a file at the end.

Am I wrong in assuming Chuck writes directly to disk? Perhaps we could solve this problem by allowing the option to write to a buffer instead?

Thoughts appreciated!

Jordan

[Kassen]

Hi, Jordan, Welcome on board!


What "known issue" do you mean? I have to say I wasn't aware of one.

[Gear Addict]

Ohh, just in regards to dropping / losing samples... do you experience this also?

Best regards,
Jordan

Edit: I attached a sound file of what I experience (converted to a mp3 to make the file smaller). The code is pretty much identical to rec-auto.ck (http://chuck.cs.princeton.edu/doc/examples/basic/rec-auto.ck) only im using adc instead of dac => Gain g => WvOut w => blackhole; to mimic how I was using WvOut in my larger recording program. For this, I simply played a song in quicktime, set my computer output to soundflower, and set soundflower as my input in ChucK.

You can hear the samples dropping almost immediately, at about 20 seconds, its pretty good until 49 seconds, then it starts dropping again. My buffer was set to 2048, but I experience this at any other buffer size as well.

I guess my question was in regards to how Chuck handles the incoming data, if it writes it directly to disk or if it records the stream to a buffer, and then writes it to disk at the end as I experienced a similar issue in Minim/Java when recording directly to disk, but no issue when recording to a buffer.

Anyway, would be great to know if you experience this also!

Cheers,
J

---

test.mp3
Description:		Download
Filename:	test.mp3
Filesize:	635.87 KB
Downloaded:	134 Time(s)

---

[Inventor]

I get this also, but only when recording from the adc. ChucK is strongly timed, meaning that even if your operating system idles it and the audio stutters, it will properly record every single sample just as soon as it gets the CPU again. However, for the case of adc, ChucK cannot listen while your computer denies it CPU. Or at least that's how I imagine it to be. Try shutting down other applications while recording, that may at least help.

It's also well known that ChucK is a real CPU hog, so that may contribute to the problem.

Les

[Gear Addict]

Thanks for the reply Les. I did a quick test (with all unnecessary applications closed) viewing Activity Monitor while doing the WvOut from adc. While admittedly the tests were not the most "scientific," I logged the time I saw spikes in the writing to disk display. These seemed to correspond with the areas in the outputted file with problems, and when checking other displays in activity monitor (CPU, Memory...etc), there were no signs of spikes or bottlenecks (lots of free memory, I have 4gb and CPU was running super low).

This made me remember that in my original encounter with this issue, I was actually listening to the output while recording from ADC through headphones, which is how I noticed it to begin with. I also had Chuck creating/sounding a metronome, while recording audio+sensor information from people playing an instrument and the metronome would suddenly hiccup and the audio jitter..

It's possible it could be a cpu thing, however, viewing activity monitor, I didn't notice any real hard cpu usage... just the corresponding spikes in hard-drive Data written / sec under Disk Activity. Also, according to Activity Monitor, looking at CPU statistics, %User = 13%-14% while recording, and %system = 4%-5%, with around 80% idle.

hm...

[Blue Hell]

Windows Vista I assume?

I've seen situations where audio buffers of 5 s are not large enough to give proper audio operation under Vista.

[Kassen]

[Blue Hell]

[Gear Addict]

It is very interesting that WvOut doesn't seem to exhibit these behaviors when dealing with ChucK generated sound, and only with ADC input.

As a note, when SoundFlowering audio from quicktime into chuck/adc, and listening to the playback of the sound through quicktime, I don't hear any issues while recording, just when listening to the exported file, however, when I listened to the output of chuck (a chuck generated metronome) as it recorded (in my past experiments) I could hear the issues in real-time (metronome would, skip, stop, restart..etc).

Perhaps this is a scheduling / priorities thing as you suggested. Is there any way for me to play around with that?

[Kassen]