Re: Please read and speak up! (was RE: [Squeak-VMdev] RE: Pending 3.2 and VM sources @ sourceforge)

[Lex S. <le...@cc...>]

Ian Piumarta <ian...@in...> wrote:
> > If so, and thus the question is the Squeak code, you might look at the
> > OSS code on SourceForge.
> 
> This is the code I started with.  I fell over the recording problems while
> testing the merge from SF last week.  (FWIW, sound is the last of the
> merges: everything else was done 10 days ago. ;-)  

Super!

> > It's not full duplex, but that's because
> > the last time I checked full-duplex didn't work in the image, either.
> 
> Preferences at: #canRecordWhilePlaying.

That wasn't the issue.  It was something along the lines of:
StartRecording does not get called if CanRecordWhilePlaying is turned
on.


> (Tip-of-the-week #2: `Preferences at: #stopSoundWhenDone put: true' will
> make Squeak coexist much more amicably with any other sounds apps that
> might be interested in opening /dev/dsp from time to time.)

Right.  Though using a sound server is nice, too.  :)  All the new
GUI_ish programs for Linux seem to support at least one sound server --
new Linux programs seem to make a lot more beeps and bloops than
traditional Unix programs would!


> > There are some functions squeakToCard()
> > and cardToSqueak() which might be handy, even if you rewrite all the rest
> > of it.
> 
> Oops -- I think the format conversions were the first thing I decided had
> to go. ;-)  They now don't contain any tests at all: there is one
> convertor for every possible combination of { squeak, driver } x { size,
> end, sign, channels }

That's cool too.  I decided not to do it that way because the CPU usage
was already pretty small.  But if you are writing individual conversion
routines, then macro tricks are great!


> > Incidentally, the formats are different for recording and playback.
> 
> The only difference that I've spotted is that recording is always mono
> whereas playback has the choice.


There is a difference in the handling of stereo: with playback, monaural
sounds are encoded as stereo but with one chanel always set to 0.  With
recording, monaural sounds are encoded with just one chanel.

Also, I don't see why recording could not be stereo -- there is a flag
for it in StartRecording.


> I'll get back to you if/when I suspect something in the image smells
> funny.  So far I can happily record and playback in half-duplex, so the
> formats don't seem to be a problem.  The real headache is getting the
> timing just right with full-duplex: the fragment size can be different (so
> there's no single, simple relationship between read/write timing) and
> select() is utterly useless because (i) it says "write me" when the image
> refuses to write less than 100 frames and (ii) it says "read me" when as
> little as one frame is available

True, but in what case will this happen?  The device should still be
operating a fragment at a time.  The only bad case I can think of is
because of the 100 frame limitation: the device may have 10 frames left
in a fragment, but Squeak might refuse to use them.  If that limitation
were removed, then select() would work fine, wouldn't it?


Lex