|
»
last call: ALC_EXT_disconnect
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
last call: ALC_EXT_disconnect
by Ryan C. Gordon-2
::
Rate this Message:
I never officially published this extension, so this is a last call for comments on it before I do so. http://icculus.org/alextreg/wiki/ALC_EXT_disconnect --ryan. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
|
|
|
|
|
|
Re: last call: ALC_EXT_disconnect
by Guilherme Balena Versiani
::
Rate this Message:
From Chris Robinson:
> And I don't like the idea of the enumeration strings only being valid until > the next query for them. IMO, the enumerations should change only when the app > calls something new, so existing behavior won't be changed and risk breaking > apps that rely on it. What do you mean by "the enumerations should change only when the app calls something new"? -- Guilherme Balena Versiani. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Ryan C. Gordon-2
::
Rate this Message:
> I mentioned it in a message to the openal list a few days ago. Whoops, sorry, I missed that. > I don't think it's necessary to specify the behavior of alcOpenDevice(NULL), > as in question 3, as that's implementation/system behavior that is not really > affected by this extension. OSX already does it without this extension, and > having this extension doesn't guarantee that behavior. This language was put in there specifically for Mac OS X. It's only in a Q&A entry and not spec-enforced behaviour, though. It's just meant to be an assurance that if your OS already does this, it may continue to do so (on the Mac, play something in iTunes, and change your default output device in System Preferences while doing so. iTunes will seamlessly migrate audio to the new device. This is user-expected behaviour on the platform, but not on others). > And I don't like the idea of the enumeration strings only being valid until > the next query for them. IMO, the enumerations should change only when the app > calls something new, so existing behavior won't be changed and risk breaking > apps that rely on it. All four implementations in OpenAL's svn repository already do redetects during alcGetString() (OpenAL-Soft caches the unchanging value, but may do the initial detection in this call, depending on when the app called it), and so does mine. Keeping this string stable across queries breaks existing, albeit undefined, behaviour. --ryan. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by E. Wing
::
Rate this Message:
On 8/18/09, Ryan C. Gordon <icculus@...> wrote:
> > I never officially published this extension, so this is a last call for > comments on it before I do so. > > http://icculus.org/alextreg/wiki/ALC_EXT_disconnect > To be pedantic, I am concerned there is a potential contradiction/ambiguity between the "What happens to queued buffers when a device is disconnected?" and "What should the AL do in the case of the default device". The first line of the first question is: "all playing sources will be stopped on disconnected". If this is to be interpreted strictly, then that may contradict the possibility or usefulness of the following question which allows the implementation to switch devices transparently where I would expect the playing sources to continue playing. I also wanted to put this idea out there. What do people think of having a callback function you can define (via function pointers) to handle device changes? It seems that constantly polling for a device change is awkward at best. I know OpenAL doesn't have any event callbacks, but maybe looking forward to future revisions, maybe this is desirable. Trying to pull an example of an API that has both polling and event driven aspects off the top of my head, I think of Zeroconf. Apple's DNS Service Discovery API fits with the traditional BSD sockets model and works with polling oriented select based code. But they have a callback system to make it easy to handle certain events. I was under the impression that Avahi's implementation does the same. Thanks, Eric _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Ryan C. Gordon-2
::
Rate this Message:
> The first line of the first question is: "all playing sources will be > stopped on disconnected". If this is to be interpreted strictly, then > that may contradict the possibility or usefulness of the following > question which allows the implementation to switch devices > transparently where I would expect the playing sources to continue > playing. I clarified the transparent switching section to say that that case isn't treated as a disconnect. > I also wanted to put this idea out there. What do people think of > having a callback function you can define (via function pointers) to > handle device changes? It seems that constantly polling for a device > change is awkward at best. I know OpenAL doesn't have any event > callbacks, but maybe looking forward to future revisions, maybe this > is desirable. It's not a very GL-like thing to do, which is sort of a guiding principle of OpenAL, for better or worse. Then again, GL is building a scene on frame at a time and it's not time sensitive, so maybe this is worth considering. It's definitely something that should go into another extension (even if one of the callbacks becomes disconnect notification and amends ALC_EXT_disconnect). --ryan. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Chris Robinson-5
::
Rate this Message:
On Wednesday 19 August 2009 6:17:44 am Ryan C. Gordon wrote:
> > I don't think it's necessary to specify the behavior of > > alcOpenDevice(NULL), as in question 3, as that's implementation/system > > behavior that is not really affected by this extension. OSX already does > > it without this extension, and having this extension doesn't guarantee > > that behavior. > > This language was put in there specifically for Mac OS X. It's only in a > Q&A entry and not spec-enforced behaviour, though. It's just meant to > be an assurance that if your OS already does this, it may continue to do > so I see. But then, I'm not sure it should be just alcOpenDevice(NULL) that can behave that way. I'm sure OSX has a string that opens the same device as the NULL device, and I believe PulseAudio can jump devices like that too, and that may not be the NULL device. IMO, I think it should just be clarified that an ALCdevice isn't considered disconnected by OpenAL while the ALC_CONNECTED property returns ALC_TRUE. Whatever the implementation or system does is up to the implementation/system, but as long as ALC_CONNECTED is ALC_TRUE, everything will continue to function as normal regardless of physical (dis)connects. > > And I don't like the idea of the enumeration strings only being valid > > until the next query for them. IMO, the enumerations should change only > > when the app calls something new, so existing behavior won't be changed > > and risk breaking apps that rely on it. > > All four implementations in OpenAL's svn repository already do redetects > during alcGetString() (OpenAL-Soft caches the unchanging value, but may > do the initial detection in this call, depending on when the app called > it), and so does mine. Keeping this string stable across queries breaks > existing, albeit undefined, behaviour. Hmm, okay. If possible then, something I'd like to have noted is that the device list may not update if there's devices open (capture or playback, disconnected or not). Re-probing devices could require unloading and reloading the backend libs, and you can't do that if there's a device open using the libs. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Chris Robinson-5
::
Rate this Message:
On Wednesday 19 August 2009 4:01:47 am Guilherme Balena Versiani wrote:
> From Chris Robinson: > > And I don't like the idea of the enumeration strings only being valid > > until the next query for them. IMO, the enumerations should change only > > when the app calls something new, so existing behavior won't be changed > > and risk breaking apps that rely on it. > > What do you mean by "the enumerations should change only when the app > calls something new"? Basically either a new enumerant (calling alcGetString with something other than ALC_DEVICE_SPECIFIER), or a new function, to tell the lib that it's okay to change the device list(s) now. At that point, any pointers retained from previous calls would be considered invalid. Apparently that's not needed though, since OSX and Windows can change the list with normal calls to alcGetString with ALC_DEVICE_SPECIFIER. I figured it couldn't do that since it returned a pointer to const memory and the spec said nothing about further calls invalidating previous ones. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Chris Robinson-5
::
Rate this Message:
On Wednesday 19 August 2009 6:19:05 am E. Wing wrote:
> I also wanted to put this idea out there. What do people think of > having a callback function you can define (via function pointers) to > handle device changes? It seems that constantly polling for a device > change is awkward at best. I know OpenAL doesn't have any event > callbacks, but maybe looking forward to future revisions, maybe this > is desirable. Normally I wouldn't be for callbacks. However, as long as it's restricted to the system-level ALC API it may not be that bad. Only concern I would have is what kind of execution context could be said about the callback? Could it be in a real system-level interrupt (rest of the app is stopped)? A background thread (eg. the mixer)? The "main" thread (where the last app call to AL occurred)? And what about blocking and re-entrancy, given OpenAL's thread- safety? _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Bob Aron
::
Rate this Message:
Ryan,
From the description text: " Once a device is disconnected, it will never become reconnected. Even if the user plugs the device back in, the application must
close the existing zombie device handle and reopen it with
alc*OpenDevice().
" If the device never becomes valid again, then what is happening to the created contexts that were passed what would now be the dead device? It seems to imply the application would have to maintain the state of all it's context and source settings so it could restore them to a new context created with a new device? -bob ____________________________________________ CoreAudio Team • Apple Inc. On Aug 18, 2009, at 11:00 PM, Ryan C. Gordon wrote:
_______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Forrest Voight
::
Rate this Message:
> If the device never becomes valid again, then what is happening to the
> created contexts that were passed what would now be the dead device? It > seems to imply the application would have to maintain the state of all it's > context and source settings so it could restore them to a new context > created with a new device? You're already forced to do that with OpenGL when changing context attributes. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Ryan C. Gordon-2
::
Rate this Message:
> If the device never becomes valid again, then what is happening to the > created contexts that were passed what would now be the dead device? It > seems to imply the application would have to maintain the state of all > it's context and source settings so it could restore them to a new > context created with a new device? Yes, that is true. It seems to be more reasonable, since the app was able to generate the data in the first place. If the implementation guaranteed the state, we'd probably end up with two copies in memory, and make the driver writers angry. :) Alternately, in theoretical cases where the hardware is storing the buffers (like texture memory on a video card), the AL might not have a copy at all, and not have time to recover the data if the hardware is being yanked out...but the application could grab the original data from disk and reupload easily. We _could_ make it easier for apps, I suppose, but it seems like this is the best compromise for everyone. Also: I added a note that alcCreateContext() on a zombie device will fail. --ryan. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Ryan C. Gordon-2
::
Rate this Message:
> IMO, I think it should just be clarified that an ALCdevice isn't considered > disconnected by OpenAL while the ALC_CONNECTED property returns ALC_TRUE. > Whatever the implementation or system does is up to the implementation/system, > but as long as ALC_CONNECTED is ALC_TRUE, everything will continue to function > as normal regardless of physical (dis)connects. That's a good idea...that'll really clean up the spec. > Hmm, okay. If possible then, something I'd like to have noted is that the > device list may not update if there's devices open (capture or playback, > disconnected or not). Re-probing devices could require unloading and reloading > the backend libs, and you can't do that if there's a device open using the > libs. I don't know, there's no reason an implementation couldn't impose that requirement (it simply won't list new devices if it can't at the moment), but I don't think it should be spec-enforced. Most lowlevel implementations wouldn't need that requirement, but I could see a high level wrapper AL thingy having that issue. --ryan. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Ryan C. Gordon-2
::
Rate this Message:
Unless any other concerns pop up, this extension will be considered finalized, and will be published on the alextreg at noon tomorrow. --ryan. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by E. Wing
::
Rate this Message:
>
>> I also wanted to put this idea out there. What do people think of >> having a callback function you can define (via function pointers) to >> handle device changes? It seems that constantly polling for a device >> change is awkward at best. I know OpenAL doesn't have any event >> callbacks, but maybe looking forward to future revisions, maybe this >> is desirable. > > It's not a very GL-like thing to do, which is sort of a guiding > principle of OpenAL, for better or worse. > > Then again, GL is building a scene on frame at a time and it's not time > sensitive, so maybe this is worth considering. It's definitely something > that should go into another extension (even if one of the callbacks > becomes disconnect notification and amends ALC_EXT_disconnect). > So I'm not suggesting any more changes to ALC_EXT_disconnect, but just wanted to quickly follow up on the idea of callback notifications. So one thing that strikes me about applying the OpenGL mentality to OpenAL is that in OpenAL, we constantly violate the cardinal optimization rule of OpenGL: never use glGet*. In OpenGL, we go to great lengths to shadow state so we never have to query the graphics system. In contrast, with OpenAL, shadowing for certain core things is difficult, imprecise, and sometimes unreasonable. We tend to query to find when a source stopped playing. We pretty much have to query to use the buffering queuing system to clear out processed buffers. And for capture, we have to query to find out how many samples are currently available. In my mind, we are already being un-OpenGL like because I have it ingrained in my head to avoid glGet*. Perhaps it's just me. Anyway, my 2 cents. Thanks for listening, Eric _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by E. Wing
::
Rate this Message:
On 8/19/09, Chris Robinson <chris.kcat@...> wrote:
> On Wednesday 19 August 2009 6:19:05 am E. Wing wrote: >> I also wanted to put this idea out there. What do people think of >> having a callback function you can define (via function pointers) to >> handle device changes? It seems that constantly polling for a device >> change is awkward at best. I know OpenAL doesn't have any event >> callbacks, but maybe looking forward to future revisions, maybe this >> is desirable. > > Normally I wouldn't be for callbacks. However, as long as it's restricted to > the system-level ALC API it may not be that bad. Only concern I would have > is > what kind of execution context could be said about the callback? Could it be > in a real system-level interrupt (rest of the app is stopped)? A background > thread (eg. the mixer)? The "main" thread (where the last app call to AL > occurred)? And what about blocking and re-entrancy, given OpenAL's thread- > safety? These are all terrific questions. I thought about trying to answer them, but on reflection, I don't think I'm qualified. I do think it would interesting to see what other people and platforms do. Maybe since we are mainly talking about USB device disconnects, do any of the major platforms have callback APIs for their USB systems? I have seen that Apple's Core Audio uses a callback system for their Audio Queues. It might be interesting to know what their underlying design decisions were. And Apple's Core Video has a callback system called the display link which is synchronized to the video display's refresh rate. I do know it runs on a separate high priority thread. Thanks, Eric _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Stephen A.
::
Rate this Message:
On Wed, Aug 26, 2009 at 11:07 AM, E. Wing <ewmailing@...> wrote:
For what it's worth, OpenCL is using callbacks for a select few functions (open device, create context, compile kernel). These are either the moral equivalents of ALC or methods were you might wish for more information than a simple error code (i.e. a compilation log). The callbacks are also strictly optional - it is valid to specify null and ignore them. Note that callbacks are notoriously hard to bind from other languages like C# or Python, especially when they involve pointers. I'm all for adding callbacks to the API where it makes sense, as long as they remain optional and are used sparingly (ALC is a good fit). _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Ryan C. Gordon-2
::
Rate this Message:
It's published! http://icculus.org/alextreg/wiki/ALC_EXT_disconnect Go forth and implement this in your AL! --ryan. _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
|
|
Re: last call: ALC_EXT_disconnect
by Chris Robinson-5
::
Rate this Message:
On Wednesday 26 August 2009 1:31:58 pm Ryan C. Gordon wrote:
> It's published! > > http://icculus.org/alextreg/wiki/ALC_EXT_disconnect > > Go forth and implement this in your AL! I have a basic implementation set up for ALSA, OSS, and Solaris devices in the GIT/SVN version of OpenAL Soft. It'll set disconnected when it irrecoverably fails to read/write the device, and should handle the source states properly. It won't currently update the device list with changes, but I'll probably set up a dynamic way to handle that soon. Feel free to try it out. :) - Chris _______________________________________________ Openal-devel mailing list Openal-devel@... http://opensource.creative.com/mailman/listinfo/openal-devel |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
