On Aug 23, 2007, at 3:20 AM, John M McIntosh wrote:

> Twitch. Sound Recording primitives
>

Ha! You should get that checked ;)


I'm not having any problems with sound buffers - the SoundRecorder  
instance is working fine - I can play and record without issues. The  
issue I'm having is in getting a wav version of the data without  
writing it to a file. If I write to a file using  
#storeWAVOnFileNamed: and read it again, it's fine. If I use  
#storeWAVSamplesOn: with a stream, the resultant buffer is not  
usable. The only difference I can see is in the type of Stream that  
is being passed into #storeWAVSamplesOn:, as that method is also  
called from #storeWAVOnFileNamed:


I'm setting my stream to binary, but I see that the binary message  
does distinctly different things between a FileStream and  
RWBinaryOrTextStream...

I'm stumped at this point, but I'm no expert on Streams either.

- Brian


> I can't say I've heard anyone complain they are failing because  
> there is GC activity.
>
> Technically most VMs interface to the operating system sound api by  
> allocation
> platform specific structures, then usually record sound into a  
> buffer area allocated
> by the SoundPlugin or Operating system, when it's full (or whatever  
> the condition is) the semaphore
> setup by SoundRecorder>>startRecording is signaled by the  
> SoundPlugin. Which
> wakes up the task waiting for the VM to provide a buffer.
>
> The SoundRecorder>>recordLoop then invokes
> primRecordSamplesInto:startingAt:  which is responsible for moving  
> the recorded sound
> data from the platform specific area into the Smalltalk SoundBuffer  
> instance.
>
> At no time does the VM sound recording logic talk directly to any  
> smalltalk object, and the
> primRecordSamplesInto:startingAt should move the data in a  
> monotonic process without any
> GC interference.
>
> I'd check in recordLoop exactly what the data is that is coming out  
> of the primitive  It could be not what you think.
>
> primRecordSamplesInto:startingAt:
>
>
> Now the other issue is I'm not sure you identified the platform and  
> VM you are using.
> It's always possible if you have multiple input devices perhaps the  
> one we are reading from
> is not the one you think you are using.
>
>
> Bugs in the last year or so:
>
>> 	"workaround for OSS emulation on top
>> 	on ALSA (on Linux environments)"
>> 	(Delay forMilliseconds: 20) wait.
>
> This code in 3.9  ""dgd" on April 4, 2006:"
> would make the macintosh carbon and unix VM drop data since it was  
> messing up the ability of the recording loop to
> empty out the buffer, so you lost data. This resulted in only  
> recording 50% of the actual data, so you recorded 20 seconds
> of audio, but on playback got 10 seconds.
>
> Crash
>
> On the macintosh carbon (fixed) and unix VM (not fixed) the  
> SoundPlugin logic would ask the recorder to stop, this would signal to
> the os-x core audio to stop, and then it would cleanup the data  
> structures. However because the core audio is running on multiple  
> pthreads it was possible to have a race condition between the  
> cleanup and the possible last write of data from the hardware  
> abstractions layer which resulted in a crash. The solution was to  
> check the data structures carefully before use and toss that last  
> couple of bytes of data if needbe.
>
> On Aug 23, 2007, at 1:38 AM, Igor Stasenko wrote:
>
>> On 22/08/07, Brian Brown <rbb at techgame.net> wrote:
>>>
>>> On Aug 22, 2007, at 12:35 PM, Hans-Martin Mosner wrote:
>>>
>>>> You're probably not resetting the ReadWriteStream. As it is  
>>>> positioned
>>>> at the end after writing, reading up to end will return 0 bytes :-)
>>>>
>>>
>>> True! That worked as far as getting some data... unfortunately, the
>>> audio is just white noise!
>>>
>>
>> This can be signs of GC actions. Squeak GC is moving GC, so it
>> possible that buffer you using for capturing sound is moved in  
>> memory,
>> and stream doesn't aware of it and reads data from old region of
>> memory, which replaced by other data.
>>
>>
>>
>>> If I write out the audio using #storeWAVOnFileNamed: at the same  
>>> time
>>> I use #storeWAVSamplesOn: the file I write to disk is normal, but  
>>> the
>>> other one is worthless.
>>>
>>> If I look them with a binary editor, they are definitely different.
>>>
>>> Any other ideas?
>>>
>>> - Brian
>>>
>>>
>>>
>>
>>
>> -- 
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
> --
> ====================================================================== 
> =====
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http:// 
> www.smalltalkconsulting.com
> ====================================================================== 
> =====
>
>
>