Audio, Streams, and MailMessage question

John M McIntosh johnmci at smalltalkconsulting.com
Thu Aug 23 09:20:47 UTC 2007


Twitch. Sound Recording primitives

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
======================================================================== 
===





More information about the Squeak-dev mailing list