Chris Robinson wrote:
Since it seemed to be caused by setting contexts, I tracked it down to the
setAttributes call. Setting the device attributes once on creation instead of
every time the context changed cleared up problem.
While I can see what was attempted with resetting the attributes on context
change, I don't believe it is correct. In certain (non-ideal) situations, the
context can be changing several times a second, and apparently ALSA doesn't
like that. But even if it did work, I can only imagine what it'll sound like
if the two contexts have different playback rates..
I think the correct way to handle seperate attributes would be to have a
per-context mixer, or perhaps opening a new device for each context. Though
we could also just not worry about it and only allow rates the device was
opened with, or attempt to set the attributes on first context creation (the
Windows version only allows for one context per device, so I don't foresee
enforcing one sample rate to be an immediate problem for code that's made to
be portable).
Attached is a preliminary patch. This also fixes a problem with the (now
removed) alcDeviceSet_ function generating an error, but not having
alcMakeContextCurrent fail. The patch should work as-is, but it's missing
frequency and refresh rate enforcement in alcCreateContext (which is supposed
to fail if the given attributes can't be honored). I'm too tired right now,
but I should be able to do that first thing later.
And speaking of context attributes, I think ALC_SYNC should be disallowed (and
the relevant syncronous mixer code removed), until the mixer itself gets
properly restructured and it can be properly handled. It'll be a lot easier
to fix the mixer if it can be cut down in complexity. It can be re-added when
the mixer is fixed up, but as it is, I can see many problems if someone tries
to mix asyncronous and syncronous contexts. The Windows version does not
allow syncronous mixing, so again, not a problem for portable code.
The only thing I would worry about with this suggestion is breaking any
existing programs that are relying on it.
That said, I just made the rather surprising realization that while the
spec introduces the ALC_SYNC flag as a context attribute for "indicating
a synchronous context", it makes absolutely no mention of what exactly a
synchronous context is, or why you might want to create one (this is
also true of the old 1.0 spec written by Loki). I vaguely remember
tracing through a very early implementation to see what synchronous
contexts did, but I don't remember how they worked.
I don't think I've ever heard of anybody posting to the list about it or
needing to use it for whatever reason. My guess would be that nobody
would notice if you removed it, but I'd at least wait for a couple of
other opinions before starting with that.
--
--"J"
"I'm a castaway stranded in a desolate land,
I can see the footprints in the virtual sand."
--Neil Peart
|
| 
