Menu
▾
▴
squeak-vmdev
|
From: <gor...@bl...> - 2002-05-15 07:28:49
|
Rob Withers <rwi...@at...> wrote: [SNIP] > I think we just tag the main trunk for the major releases. This way we > can get back to that point for testing reported bugs, etc. I pretty > much see everyone hacking in the trunk and this will cause ongoing > problems of inconsistent platform support for new features. We have > been fighting this since day one of using SF with VMMaker, but the > response time is typically very short. I don't know how we can resolve > this. Eh, have you (and everyone else) read Ian's, mine and others postings on the proposed "work model"? If not then please do - it is the larger posts in this thread starting with one from Ian I believe. :-) I am actually waiting for people to say "Ok, let's do it that way." so that: - Andreas and Ian joins up. And anyone else that was hesitating before. - I can sit down and write the "CVS howto + policy draft" so that chaos and confusion does not need to reign. - Everyone is happy. regards, Göran |
|
From: Andreas R. <And...@gm...> - 2002-05-15 10:30:53
|
> I am actually waiting for people to say "Ok, let's do it that way." > so that: I thought I said that already ;-) So "let's do it that way". Cheers, - Andreas |
|
From: Bert F. <be...@is...> - 2002-05-15 10:51:36
|
On Wed, 15 May 2002, Andreas Raab wrote: > I thought I said that already ;-) So "let's do it that way". I'm in. Surely Goran's policy document will clarify the actual procedure. I think we should put it at http://squeak.sourceforge.net, which is the most obvious location people will be looking for information. That URL maps to /home/groups/s/sq/squeak/htdocs on your SF shell account. Currently there is only a PHP script redirecting traffic to http://sourceforge.net/projects/squeak ... -- Bert |
|
From: Tim R. <ti...@su...> - 2002-05-15 20:04:29
|
I'll happily agree to this; especially if we can then make sqcvs tools that make it difficult to screwup :-) tim |
|
From: Andreas R. <And...@gm...> - 2002-05-20 11:37:36
|
Hi Guys, Just to let you know: With a variation of Hendriks CS (which he just sent to the Squeak mailing list) 3.3a is back in the VMBuilder arena. I've posted a slight variation of Hendriks CS, opened a VMMaker in 3.3a "generated all", typed "build" and it built out of the box. Yayy! Cheers, - Andreas |
|
From: Dan I. <Da...@Sq...> - 2002-05-20 13:28:58
|
>Hi Guys, > >Just to let you know: With a variation of Hendriks CS (which he just >sent to the Squeak mailing list) 3.3a is back in the VMBuilder arena. >I've posted a slight variation of Hendriks CS, opened a VMMaker in 3.3a >"generated all", typed "build" and it built out of the box. Yayy! > >Cheers, > - Andreas Yayy! This is great news, guys! - D |
|
From: Ian P. <ian...@in...> - 2002-05-23 10:55:40
|
On Wed, 15 May 2002 gor...@bl... wrote: > I am actually waiting for people to say "Ok, let's do it that way." Ok, let's do it that way. > - Everyone is happy. I'll be happy when I persuade the OSS recording code to produce something other than silence, 144 dB noise, VM freeze or kernel panic. (The last one's my fault for thinking it might work better with the 2.4.19-pre8 drivers. Stupid me. ;-) Ciao, Ian |
|
From: Lex S. <le...@cc...> - 2002-05-23 17:55:44
|
On Thu, May 23, 2002 at 12:55:31PM +0200, Ian Piumarta wrote: > > - Everyone is happy. > > I'll be happy when I persuade the OSS recording code to produce something > other than silence, 144 dB noise, VM freeze or kernel panic. (The last > one's my fault for thinking it might work better with the 2.4.19-pre8 > drivers. Stupid me. ;-) Does "cat < /dev/dsp > testfile" and then "cat testfile > /dev/dsp" work? ie, is recording working at all on your Linux box? If so, and thus the question is the Squeak code, you might look at the OSS code on SourceForge. It's not full duplex, but that's because the last time I checked full-duplex didn't work in the image, either. Anyway, getting full duplex to work should be a lot easier than getting all the format conversions to work. There are some functions squeakToCard() and cardToSqueak() which might be handy, even if you rewrite all the rest of it. Incidentally, the formats are different for recording and playback. I posted a changeset that updates the comments for this, but I don't know if they got included in any image. I can dig up those comments again if it would help -- it took me a few hours to trace it all down! Lex |
|
From: Ian P. <ian...@in...> - 2002-05-23 20:49:27
|
Hi Lex, > Does "cat < /dev/dsp > testfile" and then "cat testfile > /dev/dsp" work? > ie, is recording working at all on your Linux box? Actually it's better than that. On my PowerBook (OSS/dmasound and AWACS low-level driver): cat < /dev/dsp > /dev/dsp works just fine (and as it says somewhere on opensound.com, the above makes me a perfectly serviceable "cheesy little delay line" ;-). FWIW, SNDCTL_DSP_GETCAPS reports DSP_CAP_DUPLEX for dmasound/AWACS, so I'd expect to be able to open the same device twice. On Intel (nm256av + ac97 drivers): cat < /dev/dsp > /dev/dsp fails (resource not available), but cat < /dev/dsp > /dev/dsp1 works just fine. DSP_CAP_DUPLEX is not reported for the nm256, so I shouldn't expect to be able to open the same device twice -- and /dev/dsp and /dev/dsp1 do indeed seem to be different devices with dsp1 being the output half and dsp being the input half (but which also knows how to turn into a "shadow" of dsp1 when it's opened for writing). The above is all pretty much consistent with what it says in the latest OSS API documentation. For AWACS I can also open /dev/dsp O_RDWR (as claimed in the OSS doc for DSP_CAP_DUPLEX devices) and then perform both i and o through the same fd. (This locks both directions into the same format/rate/channels, but that's a bug in the OSS API and not an intrinsic limitation in the AWACS LL driver.) > 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. ;-) I've spent the intervening time learning more than I ever really wanted to about low-latency sound programming in general, OSS in particular and the internals of its low-level drivers in gorey detail. (But I'm a much wiser, and therefore happier, hacker now. ;-) (Once I got the output timing sorted out properly Squeak immediately dropped to between 0.1 and 0.5 % CPU while playing the stereoBachFugue -- which makes me realise just how _much_ dsp could potentially be done in Squeak without ever risking underruns...) > 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. (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.) > Anyway, getting full duplex to work should be a lot easier than getting > all the format conversions to work. That's what I thought... but the format conversions turned out to be utterly trivial and timing issues are turning out to be a horrendous nightmare. > 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 } (which comes to 24 converters after you've deleted the meaningless ones -- and just 24 lines of code when you've figured out the right macros ;-) where each one is a trivial, tight, ultrafast loop. Appropriate input/output converters are chosen when the device format is queried/set after opening dsp. Overhead: one indirect fn call per buffer's worth of i or o. I decided the rest had to go when I started trying to do full duplex. In short: 1. Everything now respects *rigorously* the OSS API. 2. The image was spending most of its time in tight loops because of the (inconsistent) way it uses the semaphores, the arbitrary 100 frame minimum in output, and the arbitrary min read size for input based on the buffer allocated in the image. 3. The conversion routines are now optimal (modulo any weirdo string handling insns that the compiler might not be clever enough to emit). 4. select() is basically useless for full-duplex sound i/o. 5. Different cards have different capabilities so any one of two (and a half ;) mutually incompatible mechanisms might be needed to achieve full-duplex in all cases where it's possible. 6. The old code had more bubble gum and scotch tape holding it together than it had actual implementation. And maybe this is a teeny bit extreme, but... 7. Doing things "right" in the Squeak code panics the latest Linux kernel: the perfect incentive to go fix the kernel! (The problem is obvious and seems trivial to fix, so I'm sucking in bitkeeper repositories as I type... ;-) > 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. (So initiating recording when stereo playback is already active, with a driver like dmasound which imposes the same # channels for full-duplex [rather stupidly since the LL drivers can happily cope with different formats in duplex] will cause SNDCTL_DSP_CHANNELS to answer `2' when 1 channel is requested and the support code to subsequently select a 2->1 channel converter correctly. Seems to work. If you have pathological cases, I'm interested!) > posted a changeset that updates the comments for this, but I don't know > if they got included in any image. I can dig up those comments again if > it would help -- it took me a few hours to trace it all down! 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 -- both of which tend to keep the player/recorder processes in such tight loops that the image has a hard time getting screen updates out, let alone noticing incoming keyboard interrupts. Regards, Ian PS: There's a performance bug in the player process. Rather than [ [self isSpaceAvailable] whileFalse: [self twiddleThumbs]. lotsOfSounds do: [sound playInto: buffer]. self outputNoisesFrom: buffer. ] rinseAndRepeat. I think it might make more sense to pregenerate a lead time's worth of samples into the buffer before deciding whether to twiddleThumbs. Otherwise we're effectively wasting a fragment's worth of latency and/or bandwidth when lotsOfSounds and/or sample frequency is large w.r.t. CPU speed. Just a thought... |
|
From: Lex S. <le...@cc...> - 2002-05-25 18:09:49
|
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
|
|
From: Ian P. <ian...@in...> - 2002-05-25 21:10:18
Attachments:
e1.c
|
Lex,
> That wasn't the issue. It was something along the lines of:
> StartRecording does not get called if CanRecordWhilePlaying is turned
> on.
Ok, thanks. I'll watch out for this.
> Right. Though using a sound server is nice, too. :)
I'll resist the temptation (for now) to air my observations about NAS
running over the net between different endian machines. ;-)
> 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.
Ahh, I'd missed that one.
Err, then again... are you sure? Without digging as deeply as I should,
here's the beginning of playLoop:
| bytesPerSlice count willStop mayStop |
mayStop _ Preferences soundStopWhenDone.
bytesPerSlice _ Stereo ifTrue: [4] ifFalse: [2].
which seems to suggest that mono really is 1 channel.
> Also, I don't see why recording could not be stereo -- there is a flag
> for it in StartRecording.
I meant it's (currently) always set to mono in the image. (The support
code makes no assumptions about # of Squeak channels in either direction.
Everything is completely symmetric.)
> True, but in what case will this happen? The device should still be
> operating a fragment at a time.
Absolutely. There's no other way it can work, given that something is
eventually going to DMA all those samples. The problem is with select()
itself.
Try this:
- compile the attached program
- launch xmixer (or somesuch)
- select CD digital output as your recording source
- set all relevant in/out volumes so you'll here something from the CD
(analog CD and/or "monitor" at zero [if you have it] but PCM and
IGain turned up [just a little -- if you value your speakers ;])
- put a very calming CD into the drive (you'll need it ;)
- start the CD playing (with cdplay, or somesuch)
- run the program you just compiled.
If all is well you should hear music with no gaps, clicks, or repeated
fragments. The program should be printing lots and lots of `.'s
(indicating that select() is twiddling thumbs furiously) with the
occasional `r' and `w' interspersed (approx the same number of each).
On the other hand, if your OSS drivers are as broken as all those that
I've come across so far, you'll see something like this:
- lines of `rw.' with the cursor sitting mostly over the `w'. This
means that select() is saying the input device is readable even
when it isn't, and read is blocking on input.
or maybe:
- lots of repeated `.w<N' which means the input side of the device
is never being select()ed for read.
(The offending drivers ignore O_NONBLOCK too, just to add insult to
injury.)
FWIW, all of the OSS-based sound programs/daemons that I've downloaded and
autopsied in the last week (disregarding the trivial ones that just pump
data using blocking read/write) use clocked i/o rather than select().
FWIW #2, it was the first problem that started this saga. Squeak was so
stuck in blocked reads (blocking every time it did a quickCheckForIntrs)
that it became literally uninterruptable.
I wouldn't hesitate to put SIGALRM back into the VM (I've already got all
the code to implement ITIMER-based periodic "triggers") if I weren't so
terrified by the potential number of syscalls that might break from EINTR
and which are currently not checked (not to mention the amount of work
needed to resuscitate my slowly-rusting SunOS box to be absolutely sure
about it ;).
> 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?
I don't think so. It was one of the first things I tried. (I removed the
minimum limit altogether.) The only thing that did work was preventing
the output from being select()ed on each and every poll. (Failing
snd_Start when semaIndex > 0 makes the image use the old-style polling
loop. Then don't bother registering the dsp output fd with aio, and use
GETOSPACE in snd_availSpace. Works like a dream: Squeak eats zero CPU and
sound output is flawless. If the same aproach would worked for input
there would be no problem, but O_NONBLOCK is broken in several drivers
which also don't implement [or return garbage for] GETISPACE.)
So the problem really is in the totally broken interaction between the OSS
drivers and select().
I started fixing this for PowerBook (at least on the driver side) but
having been dropped into xmon for the Nth time due to a kernel exception
down in the bowels of do_select() I rapidly lost motivation for it. It's
the wrong (short-term) solution anyway: the OSS drivers are thoroughly
broken on PowerMac and NM256/AC97 (which crops up in a _lot_ of PC
hardware), and it's anybody's guess on how many others too. So I think it
makes more sense to assume an absolute minimum of functionality from the
OSS drivers (including the absence of select()) and then try to make the
VM code sufficiently intelligent to cope using only what's left.
(Or I could just give up right now and go make all my stuff compatible
with VMMaker instead, which was supposed to be the next thing on the
"to-do" list two weeks ago. ;-)
Ian
PS: A quick-and-dirty solution would be to spawn a thread to talk to the
device, connected to the VM through a pipe or two with which select()
could happily work. But this is total overkill.
|
|
From: Tim R. <ti...@su...> - 2002-05-26 15:31:34
|
In message <Pin...@ti...>
Ian Piumarta <ian...@in...> wrote:
> (Or I could just give up right now and go make all my stuff compatible
> with VMMaker instead, which was supposed to be the next thing on the
> "to-do" list two weeks ago. ;-)
Much more sensible; after all, the sound code will realise it is being
ignored and then immediately start to play nice.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Don't anthropomorphize comupters. They _hate_ that.
|
|
From: Ian P. <ian...@in...> - 2002-05-26 15:45:31
|
Hi Lex, I figure you might be interested in this. Last night I downloaded and built a 2.4.18 kernel followed by the very latest ALSA (cvs co from their development tree) with OSS compatibility enabled. It works like a dream! In particular select() is working *exactly* as it aught to, at least on PPC. I haven't checked on PC h/w yet, but since the ALSA OSS compatibility is identical for all platforms I see no reason why it shouldn't work perfectly. Unless you can think of some reason why this might be a bad idea (and given the _vast_ improvement over the native Linux OSS drivers) I propose that the Squeak OSS sound code be written/tested against the ALSA OSS compatibility driver instead. (After all, it works just like the OSS docs say it should -- which is manifestly not the case with the native sound drivers.) Anybody who has problems with sound can then be pointed at ALSA as the solution. I might have a go at native ALSA support too (just too see what it smells like ;). BTW (on a totally different topic): I really like your idea to map mod1-4 to Command and mod5 to Option (so that people at least have the chance to recover the latter with some xmodmap gymnastics). It's on the to-do list. Regards, Ian |
|
From: Andreas R. <And...@gm...> - 2002-05-28 15:08:45
|
Hi Guys, I need to do some restructuring in the 3D stuff - it turns out that I put one of the functions into the wrong place (namely the platform dependent part) and I just added some stuff that would now need to be duplicated across the various platform branches. This is as good an opportunity as ever to relocate the functions in question (namely glGetIntProperty and glSetIntProperty) into the cross platform part of it. So how shall we go about this?! Do you want me to just update the platform independent part and remove those functions from your code when you got time?! Cheers, - Andreas |
|
From: Bert F. <be...@is...> - 2002-05-28 15:29:41
|
On Tue, 28 May 2002, Andreas Raab wrote: > Hi Guys, > > I need to do some restructuring in the 3D stuff - it turns out that I > put one of the functions into the wrong place (namely the platform > dependent part) and I just added some stuff that would now need to be > duplicated across the various platform branches. This is as good an > opportunity as ever to relocate the functions in question (namely > glGetIntProperty and glSetIntProperty) into the cross platform part of > it. But glGetIntProperty is not system independent. On Mac it calls an agl* function. Or do you provide another call for this? > So how shall we go about this?! Do you want me to just update the > platform independent part and remove those functions from your code when > you got time?! I would even trust you to patch the unix part yourself, even if you do not test it. But then, the Unix version is not even checked in. I just never got around to do it. I think Cees said he got it working with VMMaker ... -- Bert |
|
From: Andreas R. <And...@gm...> - 2002-05-28 15:37:11
|
Darn! You're right - I did this for some demo of Alan (that's why it's only in the Mac stuff and I think I even introduced it there...) Guess I need to figure something out to make it behave the right way - all the glGets and glEnables just shouldn't be replicated along the various platform files. Thanks for pointing it out. And no, I don't want to hack the Unix code nor the Mac code, this is really just a synchronization issue ;-) Cheers, - Andreas > -----Original Message----- > From: squ...@li... > [mailto:squ...@li...] On Behalf > Of Bert Freudenberg > Sent: Tuesday, May 28, 2002 5:26 PM > To: squ...@li... > Subject: Re: [Squeak-VMdev] Restructuring some 3D stuff > > > On Tue, 28 May 2002, Andreas Raab wrote: > > > Hi Guys, > > > > I need to do some restructuring in the 3D stuff - it turns > out that I > > put one of the functions into the wrong place (namely the platform > > dependent part) and I just added some stuff that would now > need to be > > duplicated across the various platform branches. This is as good an > > opportunity as ever to relocate the functions in question (namely > > glGetIntProperty and glSetIntProperty) into the cross > platform part of > > it. > > But glGetIntProperty is not system independent. On Mac it > calls an agl* > function. Or do you provide another call for this? > > > So how shall we go about this?! Do you want me to just update the > > platform independent part and remove those functions from > your code when > > you got time?! > > I would even trust you to patch the unix part yourself, even > if you do not > test it. But then, the Unix version is not even checked in. I > just never > got around to do it. I think Cees said he got it working with > VMMaker ... > > -- Bert > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev > |
|
From: Andreas R. <And...@gm...> - 2002-05-29 11:48:35
|
Hi, I've updated the SF tree with the changes to the cross platform code. What *you* need to do for the individual platforms is: a) Rename the following functions in sqXYZOpenGL.c glGetIntProperty() -> glGetIntPropertyOS() glSetIntProperty() -> glSetIntPropertyOS() b) Remove any non-negative properties from the OS specific variants. Those are handled by the cross-platform part and you will never be called with a non-negative property. E.g., for win32 the above two functions just return zero since no OS specific properties are supported. For the Mac this should only handle the refresh stuff and nothing else. Cheers, - Andreas > -----Original Message----- > From: squ...@li... > [mailto:squ...@li...] On Behalf > Of Andreas Raab > Sent: Tuesday, May 28, 2002 5:08 PM > To: squ...@li... > Subject: [Squeak-VMdev] Restructuring some 3D stuff > > > Hi Guys, > > I need to do some restructuring in the 3D stuff - it turns out that I > put one of the functions into the wrong place (namely the platform > dependent part) and I just added some stuff that would now need to be > duplicated across the various platform branches. This is as good an > opportunity as ever to relocate the functions in question (namely > glGetIntProperty and glSetIntProperty) into the cross platform part of > it. > > So how shall we go about this?! Do you want me to just update the > platform independent part and remove those functions from > your code when > you got time?! > > Cheers, > - Andreas > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev > |
Thanks for helping keep SourceForge clean.
X