|
»
Max number of sources (and legit id values) for each OpenAL implementation
|
View:
New views
16 Messages
—
Rating Filter:
Alert me
|
 |
Max number of sources (and legit id values) for each OpenAL implementation
by E. Wing
::
Rate this Message:
Hi, I am writing some stuff about OpenAL and I would like to get my
facts straight. Can people verify my information about the maximum number of sources? Creative Labs: I recall seeing this in an old mailing list thread. Generic Software: 256 Generic Hardware: 16-64 OpenAL Soft: >From the source code, I do see a hard coded value of 256, but there is other conditional stuff in there so I'm thinking there might be other potential values? Mac OS X and iPhone OS: >From the source code, it looks like the max you can request at a time (to alGenSources) is 256. However, there doesn't seem to be anything stopping you from making multiple calls to alGenSources of 256 sources. Probably not the intended behavior, but interesting. Experimenting on the iPhone, the code seems to be the same here because multiple calls of 256, give me unique source ids. (I haven't been able to find the iPhone OpenAL source code.) Are there any other implementations I'm forgetting? Also, on this topic, do any implementations actually return 0 as a valid id? I know the 1.1 spec doesn't reserve any value, but this has always been a gotcha for me because in OpenGL, 0 is reserved. Thanks, Eric _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for each OpenAL implementation
by Daniel PEACOCK
::
Rate this Message:
Hi, Those numbers are correct for Generic Hardware and Generic Software. Creative ships various other OpenAL devices that support between 60 and 128 sources. We used to ship an OpenAL implementation that would return 0 for a valid Source ID. However we found some problems in the field with games that were doing things like ... if (sourceID) // found valid source do something with it instead of ... if (alIsSource(sourceID)) // found valid source do something with it So we changed our implementations to stop returning an id of 0. However, as you say, the spec. does not disallow Source IDs of 0 - so code should always use alIsSource() to validate a Source ID. Dan Creative Labs (UK) Ltd. Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you. Creative Labs UK Ltd company number 2658256 registered in England and Wales at Belmont Road, Belmont Place, Maidenhead, Berkshire, SL6 6TB "E. Wing" <ewmailing@gmail. com> To Sent by: OpenAL openal-bounces@op <openal@...> ensource.creative cc .com Subject [Openal] Max number of sources (and 07/21/2009 09:35 legit id values) for each AM OpenAL implementation Hi, I am writing some stuff about OpenAL and I would like to get my facts straight. Can people verify my information about the maximum number of sources? Creative Labs: I recall seeing this in an old mailing list thread. Generic Software: 256 Generic Hardware: 16-64 OpenAL Soft: >From the source code, I do see a hard coded value of 256, but there is other conditional stuff in there so I'm thinking there might be other potential values? Mac OS X and iPhone OS: >From the source code, it looks like the max you can request at a time (to alGenSources) is 256. However, there doesn't seem to be anything stopping you from making multiple calls to alGenSources of 256 sources. Probably not the intended behavior, but interesting. Experimenting on the iPhone, the code seems to be the same here because multiple calls of 256, give me unique source ids. (I haven't been able to find the iPhone OpenAL source code.) Are there any other implementations I'm forgetting? Also, on this topic, do any implementations actually return 0 as a valid id? I know the 1.1 spec doesn't reserve any value, but this has always been a gotcha for me because in OpenGL, 0 is reserved. Thanks, Eric _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal ForwardSourceID:NT0006DFF6 _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for each OpenAL implementation
by E. Wing
::
Rate this Message:
On 7/21/09, Daniel PEACOCK <dpeacock@...> wrote:
> Hi, > > Those numbers are correct for Generic Hardware and Generic Software. > > Creative ships various other OpenAL devices that support between 60 and 128 > sources. Thanks Daniel. That's good info. Now I recall that there is a possibility of sounds being dynamically diverted to meet other demands which means a source could refuse to play even if you've already generated it. Can this still happen with the current implementations? If so, is it limited to only the hardware based implementations? Also, I just remembered, you guys have Xbox and Xbox 360 implementations. Can you share any information on the sources for these? > We used to ship an OpenAL implementation that would return 0 for a valid > Source ID. However we > found some problems in the field with games that were doing things like ... > > if (sourceID) > // found valid source do something with it > > instead of ... > > if (alIsSource(sourceID)) > // found valid source do something with it > > So we changed our implementations to stop returning an id of 0. However, as > you say, the spec. does > not disallow Source IDs of 0 - so code should always use alIsSource() to > validate a Source ID. Thanks, that's good to know. If a 1.2 spec is ever made, I would like to see 0 be reserved for just this reason. Thanks, Eric _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for each OpenAL implementation
by Chris Robinson-5
::
Rate this Message:
On Tuesday 21 July 2009 5:49:33 pm E. Wing wrote:
> Now I recall that there is a possibility of sounds being dynamically > diverted to meet other demands which means a source could refuse to > play even if you've already generated it. Can this still happen with > the current implementations? Yes. Another process playing a sound can (temporarily) take a hardware voice a source would need, so even though you have an unused source ID, it may fail to play. Multi-channel sources also tend to need multiple hardware voices, taking away from what other sources would need. The three points of failure due to lack of hardware voices can usually be: alGenSources, alSourceQueueBuffers (if no sources are queued yet), alSourcei (with AL_BUFFER), and alSourcePlay. Technically, it can be at any time, but these are the most likely points for a hardware implementation to allocate the physical voice. Creative's hardware drivers I think do it at alSourceQueueBuffers and alSourcei. > > We used to ship an OpenAL implementation that would return 0 for a valid > > Source ID. However we > > found some problems in the field with games that were doing things like > > ... > > > > if (sourceID) > > // found valid source do something with it > > > > instead of ... > > > > if (alIsSource(sourceID)) > > // found valid source do something with it > > > > So we changed our implementations to stop returning an id of 0. However, > > as you say, the spec. does > > not disallow Source IDs of 0 - so code should always use alIsSource() to > > validate a Source ID. > > Thanks, that's good to know. If a 1.2 spec is ever made, I would like > to see 0 be reserved for just this reason. Ditto. Without a reserved source ID that's never used, it would be impossible to tell if a given ID should be valid. Using alIsSource can return false positives if the "default" source ID value happens to be used by another sound. Eg: ALuint sID = 0; alGenSources(1, &sID); // fails ... if(alIsSource(sID)) // found valid source do something with it The alIsSource can still succeed if 0 was previously allocated as a source ID. Another flag would be needed to say if a given object has successfully allocated a source or not. _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for each OpenAL implementation
by Chris Robinson-5
::
Rate this Message:
On Tuesday 21 July 2009 1:35:34 am E. Wing wrote:
> Hi, I am writing some stuff about OpenAL and I would like to get my > facts straight. Can people verify my information about the maximum > number of sources? > > Creative Labs: > I recall seeing this in an old mailing list thread. > Generic Software: 256 > Generic Hardware: 16-64 Note that the Generic Hardware device depends on the hardware. It uses DirectSound3D, so if that reports >64 (or even >256) voices, that's how many you can get. AFAIK, you can get the maximum number of sources by: ALCint nummono, numstereo; alcGetIntegerv(device, ALC_MONO_SOURCES, &nummono); alcGetIntegerv(device, ALC_STEREO_SOURCES, &numstereo); printf("Max sources: %d\n", nummono+numstereo); I'm not sure what the values for the mono/stereo sources actually mean (as Creative's software driver and openal soft report 1 for stereo sources, which is definitely not the maximum they can do, while the rest of the allocated sources are given as mono), but adding them together seems to provide the number of allocatable sources. > OpenAL Soft: > >From the source code, I do see a hard coded value of 256, but there is > > other conditional stuff in there so I'm thinking there might be other > potential values? OpenAL Soft lets the user pick the maximum number of sources in its config file, in case of apps maxing out the number of playing sources on slower systems that have trouble keeping up with the mixing. By default it provides 256.. I could've made it virtually unlimited (ie. up to 2 billion, depending on available memory), but I cautioned against that in case there were apps that allocate as many sources as the system will provide. _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for eachOpenAL implementation
by Jason Daly
::
Rate this Message:
Chris Robinson wrote:
On Tuesday 21 July 2009 1:35:34 am E. Wing wrote: That query is not in the spec. It might have been added as an extension (you'd probably know that better than me), but it's not a standard query. The only standard way to get the number of available sources is to generate them until you get an error. This might be another good candidate for a 1.2 spec, although I don't know the hardware implications of it. I think DS3D had a query for this, though, so it shouldn't be a problem... OpenAL Soft lets the user pick the maximum number of sources in its config file, in case of apps maxing out the number of playing sources on slower systems that have trouble keeping up with the mixing. By default it provides 256.. I could've made it virtually unlimited (ie. up to 2 billion, depending on available memory), but I cautioned against that in case there were apps that allocate as many sources as the system will provide. Since there's no standard query for available sources, most apps will do this, although they also typically have their own artificial cap (give me as many sources as you can, up to 256). The old SI didn't have an arbitrary limit, so an artificial cap was necessary. --"J" _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for eachOpenAL implementation
by E. Wing
::
Rate this Message:
>> Note that the Generic Hardware device depends on the hardware. It uses
>> DirectSound3D, so if that reports >64 (or even >256) voices, that's how >> many >> you can get. >> > >> OpenAL Soft lets the user pick the maximum number of sources in its config >> >> file, in case of apps maxing out the number of playing sources on slower >> systems that have trouble keeping up with the mixing. By default it >> provides >> 256.. I could've made it virtually unlimited (ie. up to 2 billion, >> depending >> on available memory), but I cautioned against that in case there were apps >> >> that allocate as many sources as the system will provide. >> Chris, thanks for the detailed information. This is very helpful to me. >> AFAIK, you can get the maximum number of sources by: >> >> ALCint nummono, numstereo; >> alcGetIntegerv(device, ALC_MONO_SOURCES, &nummono); >> alcGetIntegerv(device, ALC_STEREO_SOURCES, &numstereo); >> >> printf("Max sources: %d\n", nummono+numstereo); >> > > That query is not in the spec. It might have been added as an extension > (you'd probably know that better than me), but it's not a standard > query. The only standard way to get the number of available sources is > to generate them until you get an error. > > This might be another good candidate for a 1.2 spec, although I don't > know the hardware implications of it. I think DS3D had a query for > this, though, so it shouldn't be a problem... > > > Since there's no standard query for available sources, most apps will do > this, although they also typically have their own artificial cap (give > me as many sources as you can, up to 256). The old SI didn't have an > arbitrary limit, so an artificial cap was necessary. I have seen ALC_MONO_SOURCES and ALC_STEREO_SOURCES with respect to the attribute list you can pass alcCreateContext. According to the spec, these are officially recognized values, but it is very unclear what these actually do. When sniffing around the Mac OS X source code, I discovered that these are the only 2 attributes Mac seems to not throw away. But the default for for ALC_MONO_SOURCES is 0 and the default for ALC_STEREO_SOURCES is 1. I'm expecting these are just optimization hints for the Mac implementation and these might change especially if you start throwing more stereo sources at the system. But I'm only speculating without actually testing it. I don't know what if any performance advantages there are to setting this. But from this implementation and reflecting what Jason says, I don't think the query will give me the number of available sources. Thanks for the ideas though. This has been a good discussion for me. Thanks, Eric _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for eachOpenAL implementation
by Chris Robinson-5
::
Rate this Message:
On Wednesday 22 July 2009 5:32:54 pm Jason Daly wrote:
> Chris Robinson wrote: > > AFAIK, you can get the maximum number of sources by: > > > > ALCint nummono, numstereo; > > alcGetIntegerv(device, ALC_MONO_SOURCES, &nummono); > > alcGetIntegerv(device, ALC_STEREO_SOURCES, &numstereo); > > > > printf("Max sources: %d\n", nummono+numstereo); > > That query is not in the spec. It might have been added as an extension > (you'd probably know that better than me), but it's not a standard > query. The only standard way to get the number of available sources is > to generate them until you get an error. According to the spec for alcGetIntegerv, "All tokens in table 6-2 (context creation) and table 6-4 (context query types) are valid for this call." There's a slight error there as table 6-1 is actually context creation, and 6-2 is error conditions. The error condition enums don't make much sense for the function, so table 6-1 is likely what it meant. The same table also has ALC_REFRESH and ALC_FREQUENCY (which would be useful for apps to know) with ALC_MONO_SOURCES and ALC_STEREO_SOURCES. > Since there's no standard query for available sources, most apps will do > this, although they also typically have their own artificial cap (give > me as many sources as you can, up to 256). The old SI didn't have an > arbitrary limit, so an artificial cap was necessary. Though even if apps queried for the maximum number of sources, they would need to force an artificial cap, all the same. There's nothing stopping an implementation from reporting 2^31-1 sources, but you wouldn't want an app to try blindly allocating that many up front. Apps need to treat sources as a limited resource for maximum compatibility, anyway. Testing and developing on a system with unlimited sources, and then having it run on hardware with only 64 voices, would be a rather big problem. Sources need to be managed so they can be reused/stolen/etc, on systems from as few as 16 voices, up to however many. Fewer maximum voices will of course degrade quality, but when you get up to 256 simultaneous sources, a good manager should be able to make that virtually imperceptible, I think. _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) foreachOpenAL implementation
by Jason Daly
::
Rate this Message:
Chris Robinson wrote:
> According to the spec for alcGetIntegerv, "All tokens in table 6-2 (context > creation) and table 6-4 (context query types) are valid for this call." > There's a slight error there as table 6-1 is actually context creation, and > 6-2 is error conditions. The error condition enums don't make much sense for > the function, so table 6-1 is likely what it meant. > > The same table also has ALC_REFRESH and ALC_FREQUENCY (which would be useful > for apps to know) with ALC_MONO_SOURCES and ALC_STEREO_SOURCES. > I agree that it should be 6.1. It also says that ALC_MONO_SOURCES and ALC_STEREO_SOURCES are hints. The original intent of these was to allow the app to suggest to the AL how many stereo vs. mono sources it would need, as hardware needs to know . There's no guarantee that you'll get what you request. The spec doesn't explicitly say what you get when you query those, either. I wouldn't assume that you'd get anything more than the hint value back, but I went ahead and did some digging. There isn't much about it (no one commented on it during the drafting process), but it appears that the original intent was to allow you to query the minimum number of mono and stereo buffers. This is Garin's original post when he added these tokens to the spec: http://opensource.creative.com/pipermail/openal-devel/2005-May/003068.html I guess this is my long-winded way of saying you were right and I was wrong ;-) > Though even if apps queried for the maximum number of sources, they would need > to force an artificial cap, all the same. There's nothing stopping an > implementation from reporting 2^31-1 sources, but you wouldn't want an app to > try blindly allocating that many up front. > True enough. > Apps need to treat sources as a limited resource for maximum compatibility, > anyway. Testing and developing on a system with unlimited sources, and then > having it run on hardware with only 64 voices, would be a rather big problem. > Sources need to be managed so they can be reused/stolen/etc, on systems from > as few as 16 voices, up to however many. Fewer maximum voices will of course > degrade quality, but when you get up to 256 simultaneous sources, a good > manager should be able to make that virtually imperceptible, I think. > Agreed (in most cases, at least). --"J" _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) foreachOpenAL implementation
by Daniel PEACOCK
::
Rate this Message:
Hi All, The original motivation for having the ALC_MONO_SOURCES and ALC_STEREO_SOURCES hints was due to the fact that an OpenAL Source that can be used to play buffers that could have anywhere between 1 and 8 (maybe even more) channels of data. For software mixers this is no big deal - but for hardware devices that require one voice per channel (e.g Stereo requires 2 voices) it is a big problem. If you are running on a hardware device with 128 voices then generating 128 sources and using them to play 128 mono buffers is OK - but you can't use them to play 128 Stereo buffers. As it is quite likely that an OpenAL application (likely to be a game) will play at least 1 stereo file (e.g. for music) the Creative OpenAL implementations reserve one voice so that if you generate the maximum number of sources, you can use them to play one stereo buffer and the rest mono. (You can see this by creating a context and querying the ALC_STEREO_SOURCES attributes - it will be 1). If you need to play more than one stereo voice at a time, then we recommend that you use the ALC_STEREO_SOURCES context creation hint to tell AL how many you will need to play *simultaneously*. This enables OpenAL to reserve the appropriate number of voices so that when you generate the maximum number of sources, you are guaranteed to be able to play back your requested number of Stereo buffers (and use the rest of the sources to play mono buffers). It is designed to make your life easier! If you don't do that, then your only alternative is to check that all operations involving attaching buffers to sources and play calls actually succeed. If they don't, then you need to free up some hardware voices - this normally requires attaching a NULL buffer to a Source *not* just stopping it. Dan Creative Labs (UK) Ltd. Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you. Creative Labs UK Ltd company number 2658256 registered in England and Wales at Belmont Road, Belmont Place, Maidenhead, Berkshire, SL6 6TB Jason Daly <jdaly@... u> To Sent by: Chris Robinson openal-bounces@op <chris.kcat@...> ensource.creative cc .com "openal@..." <openal@...> Subject 07/23/2009 03:13 Re: [Openal] Max number of sources AM (and legit id values) foreachOpenAL implementation Chris Robinson wrote: > According to the spec for alcGetIntegerv, "All tokens in table 6-2 (context > creation) and table 6-4 (context query types) are valid for this call." > There's a slight error there as table 6-1 is actually context creation, and > 6-2 is error conditions. The error condition enums don't make much sense for > the function, so table 6-1 is likely what it meant. > > The same table also has ALC_REFRESH and ALC_FREQUENCY (which would be useful > for apps to know) with ALC_MONO_SOURCES and ALC_STEREO_SOURCES. > I agree that it should be 6.1. It also says that ALC_MONO_SOURCES and ALC_STEREO_SOURCES are hints. The original intent of these was to allow the app to suggest to the AL how many stereo vs. mono sources it would need, as hardware needs to know . There's no guarantee that you'll get what you request. The spec doesn't explicitly say what you get when you query those, either. I wouldn't assume that you'd get anything more than the hint value back, but I went ahead and did some digging. There isn't much about it (no one commented on it during the drafting process), but it appears that the original intent was to allow you to query the minimum number of mono and stereo buffers. This is Garin's original post when he added these tokens to the spec: http://opensource.creative.com/pipermail/openal-devel/2005-May/003068.html I guess this is my long-winded way of saying you were right and I was wrong ;-) > Though even if apps queried for the maximum number of sources, they would need > to force an artificial cap, all the same. There's nothing stopping an > implementation from reporting 2^31-1 sources, but you wouldn't want an app to > try blindly allocating that many up front. > True enough. > Apps need to treat sources as a limited resource for maximum compatibility, > anyway. Testing and developing on a system with unlimited sources, and then > having it run on hardware with only 64 voices, would be a rather big problem. > Sources need to be managed so they can be reused/stolen/etc, on systems from > as few as 16 voices, up to however many. Fewer maximum voices will of course > degrade quality, but when you get up to 256 simultaneous sources, a good > manager should be able to make that virtually imperceptible, I think. > Agreed (in most cases, at least). --"J" _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal ForwardSourceID:NT0006E0B2 _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for each OpenAL implementation
by Daniel PEACOCK
::
Rate this Message:
> > Creative Labs: > > I recall seeing this in an old mailing list thread. > > Generic Software: 256 > > Generic Hardware: 16-64 > > Note that the Generic Hardware device depends on the hardware. It uses > DirectSound3D, so if that reports >64 (or even >256) voices, that's how many > you can get. The Generic Hardware implementation caps the voices count to 64, and imposes a required lower limit of 16, so the number of sources you can generate will always be in the range 16-64. Dan Creative Labs, UK _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) for each OpenAL implementation
by Daniel PEACOCK
::
Rate this Message:
Hi Eric, > Also, I just remembered, you guys have Xbox and Xbox 360 > implementations. Can you share any information on the sources for > these? The Xbox version (which I don't think we are supporting anymore) supports 64 Sources, and the Xbox360 version supports 128. Dan Creative Labs, UK _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) foreachOpenALimplementation
by Jason Daly
::
Rate this Message:
Daniel PEACOCK wrote:
Yeah, I understand that. The only thing I wasn't clear on was what you get back when you call alcGetIntegerv with ALC_MONO_SOURCES or ALC_STEREO_SOURCES. The spec calls these "hints", so it's not really clear on what you will get back (unless I'm missing something again). If I were writing an implementation, I could argue that you should only get your hint values back, but it sounds like the intent is that it should return the number of sources actually available. --"J" _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) foreachOpenALimplementation
by Daniel PEACOCK
::
Rate this Message:
Hi Jason, I would interpret the parameters as "hints" when you are passing them in to alcCreateContext - because you might not get what you are asking for. When you get the values back with alcGetIntegerv I would expect them to reflect actual available resources though. e.g If I requested 1 stereo source, and get back 1 Stereo and 62 Monos (== 64 hardware voices), this would mean I could create 63 Sources and expect to play 1 stereo and 62 monos simultaneously. Attempting to play 2 stereos and 61 monos on the 64 Sources would not be guaranteed to work (and wouldn't on hardware). If I needed two stereo sources - perhaps to do enable cross-fades of a stereo music track - then I should request 2 stereos at context creation time. In the example above I would expect to get back 2 stereos and 60 monos - and be allowed to generate a maximum of 62 Sources. Dan Creative Labs (UK) Ltd. Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you. Creative Labs UK Ltd company number 2658256 registered in England and Wales at Belmont Road, Belmont Place, Maidenhead, Berkshire, SL6 6TB Jason Daly <jdaly@... u> To Daniel PEACOCK 07/23/2009 05:10 <dpeacock@...> PM cc Chris Robinson <chris.kcat@...>, "openal@..." <openal@...> Subject Re: [Openal] Max number of sources (and legit id values) foreachOpenALimplementation Daniel PEACOCK wrote: Hi All, The original motivation for having the ALC_MONO_SOURCES and ALC_STEREO_SOURCES hints was due to the fact that an OpenAL Source that can be used to play buffers that could have anywhere between 1 and 8 (maybe even more) channels of data. For software mixers this is no big deal - but for hardware devices that require one voice per channel (e.g Stereo requires 2 voices) it is a big problem. If you are running on a hardware device with 128 voices then generating 128 sources and using them to play 128 mono buffers is OK - but you can't use them to play 128 Stereo buffers. Yeah, I understand that. The only thing I wasn't clear on was what you get back when you call alcGetIntegerv with ALC_MONO_SOURCES or ALC_STEREO_SOURCES. The spec calls these "hints", so it's not really clear on what you will get back (unless I'm missing something again). If I were writing an implementation, I could argue that you should only get your hint values back, but it sounds like the intent is that it should return the number of sources actually available. --"J" ForwardSourceID:NT0006E15E _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) foreachOpenALimplementation
by E. Wing
::
Rate this Message:
Hi all,
I have a follow up question on this. I was reminded that with the Apple implementation, there is a distinction between the maximum number of sources you can generate and the maximum number of sources you can simultaneously play (the latter being smaller than the former). So for example on the Mac (not the iPhone), you may be able to generate 256 sources, but you can only play 64 of them simultaneously (unless you tweak the cap through one of Apple's extensions). So for all the numbers collected here in this thread, do any of the other implementations make this same strong distinction (ignoring the issues of where hardware resources may suddenly be diverted for other competing reasons)? So in the ideal case, does the maximum number of generated sources == the maximum number of simultaneous playing sources? Thanks, Eric _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
|
|
Re: Max number of sources (and legit id values) foreachOpenALimplementation
by Daniel PEACOCK
::
Rate this Message:
Hi, I believe that OpenAL-Soft, Generic Software, Generic Hardware, and the host-based 'native' OpenAL implementations on host-based Creative soundcards all give the direct correspondence of maximum generated sources == max number of simultaneous Sources. The hardware based 'native' OpenAL implementations on hardware-based Creative soundcards have the issue that maximum generated sources is equal to number of available hardware "voices" at that time. e.g. running another application that uses hardware voices at the same time can cause trouble (not a common situation because who runs 2 games at once?). A more serious issue is playing multi-channel buffers on a Source will take up multiple voices, and thus prevent you playing buffers on all your generated sources simultaneously. The easiest solution to the 2nd problem is to use the context creation hint and specify how many stereo voices you need up front. Dan Creative Labs (UK) Ltd. Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you. Creative Labs UK Ltd company number 2658256 registered in England and Wales at Belmont Road, Belmont Place, Maidenhead, Berkshire, SL6 6TB "E. Wing" <ewmailing@gmail. com> To Sent by: "openal@..." openal-bounces@op <openal@...> ensource.creative cc .com Subject Re: [Openal] Max number of sources 07/30/2009 09:26 (and legit id values) AM foreachOpenALimplementation Hi all, I have a follow up question on this. I was reminded that with the Apple implementation, there is a distinction between the maximum number of sources you can generate and the maximum number of sources you can simultaneously play (the latter being smaller than the former). So for example on the Mac (not the iPhone), you may be able to generate 256 sources, but you can only play 64 of them simultaneously (unless you tweak the cap through one of Apple's extensions). So for all the numbers collected here in this thread, do any of the other implementations make this same strong distinction (ignoring the issues of where hardware resources may suddenly be diverted for other competing reasons)? So in the ideal case, does the maximum number of generated sources == the maximum number of simultaneous playing sources? Thanks, Eric _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal ForwardSourceID:NT0006E32A _______________________________________________ Openal mailing list Openal@... http://opensource.creative.com/mailman/listinfo/openal |
| Free embeddable forum powered by Nabble | Forum Help |
