John M McIntosh
johnmci at smalltalkconsulting.com
Sun Nov 26 18:19:35 UTC 2006
Ah, which explains why I couldn't see anything wrong. I'll note we
convert data from the internal recording format, to the format PCM
need by Squeak at the desired frequency using core audio, that looked
ok. Once that is done we move bytes over and did some math to convert
the bytes moved into the number of samples. I had noticed it was
clipping sound and I was earlier in the week looking at the math
involved but couldn't see anything wrong.
On 26-Nov-06, at 3:46 AM, Dominique Dutoit wrote:
> I think I have found the culprit.
> If you listen carefully to the recorded sound, you will notice that
> frames are dropped at regular intervals. Since this pattern is
> quite obvious and the VM doesn't seem to screw the sound data, it
> should be something happening at the image level.
> Looking for a clue in a 3.9 alpha version, I found a change made by
> "dgd" on April 4, 2006:
> "workaround for OSS emulation on top
> on ALSA (on Linux environments)"
> (Delay forMilliseconds: 20) wait.
> If the last line is commented out, the sound recorder just works as
> expected. The same code is present in the OLPC and Squeakland
> images and both work pretty well without this delay.
> CoreAudio records the audio input in real time but SoundRecorder
> picks the data once in a while. The end result is that the sound
> data is stored in a different time frame that the sampling rate and
> the sound plays faster.
> Now I am not sure what can be done to have a cross-platform
> solution, but as far I have seen the problem is not on the Mac VM
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Squeak-dev