<div dir="ltr">Hi,<div><br></div><div>PortAudio is definitely an option. The problem is – as always – time and engineering resources. :) Writing an FMOD backend for it is plan C or perhaps D.</div><div><br></div><div>Regards,</div><div><br></div><div>Leszek</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-07 11:00 GMT+02:00 Richard Furse <span dir="ltr"><<a href="mailto:richard@blueripplesound.com" target="_blank">richard@blueripplesound.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah, okay - I've answered completely the wrong question! I think you're saying that OpenAL is basically being used as a wrapper for the operating system audio hardware layer.<br>
<br>
Trying to think of alternatives - how is PortAudio looking these days? Does it manage to identify multichannel layouts?<br>
<br>
Best wishes,<br>
<br>
--Richard<br>
<div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: openal [mailto:<a href="mailto:openal-bounces@openal.org">openal-bounces@openal.org</a>] On Behalf Of Chris<br>
> Robinson<br>
> Sent: 07 October 2014 09:45<br>
> To: Richard Furse; 'openal mailing list'<br>
> Subject: Re: [openal] Querying speaker configuration<br>
><br>
> On 10/07/2014 01:00 AM, Richard Furse wrote:<br>
> > What's the issue here? Is this the case where there are pre-rendered<br>
> > surround assets and the upstream code wants to choose the right one<br>
> > for the speaker configuration?<br>
><br>
> In this case, the game audio is being rendered internally in real-time<br>
> (using a customized version of FMOD's software renderer), and its OpenAL<br>
> backend is used to play the mix to avoid having to code for specific<br>
> sound systems. For this situation, the game would ideally render the<br>
> audio using the same configuration OpenAL is using for output, so it<br>
> acts as close to a pass-through device as it can (e.g. if OpenAL has 5.1<br>
> output, the game's audio would be internally rendered to a 5.1 stream<br>
> and played through a typical source buffer queue using<br>
> AL_FORMAT_51CHN16/32; each input channel would then go to a matching<br>
> output channel). If OpenAL's output configuration is not understood, it<br>
> could just pick a fallback format and let OpenAL up-/down-mix it as needed.<br>
><br>
> In some cases there are secondary streams played which OpenAL will need<br>
> to mix too, but the majority of the audio is mixed and rendered internally.<br>
><br>
> This is a non-ideal use-case for OpenAL, I know, but for cases like this<br>
> where that's not really possible (it'd be quite a bit of work to fully<br>
> replace FMOD), it can be useful to know the output configuration.<br>
><br>
> > BTW, just an instinct, and without looking at the source, the<br>
> > conversation about 5.1 and stereo assets killing each other sounds<br>
> > like a classic "=" which should be a "+=" on a bus. I'm probably<br>
> > wrong, but thought I should mention it in case ;-)<br>
><br>
> Yeah, I'm not sure where that could happen, though. The actual mixer<br>
> (where the samples are added together) is the same for all inputs, be it<br>
> mono, stereo, or whatever (each input channel is processed individually,<br>
> using a set of gains for corresponding output channels). That it works<br>
> with two stereo streams, but not a stereo stream and a 5.1 stream,<br>
> suggests to me it's something wrong with the input.<br>
> _______________________________________________<br>
> openal mailing list<br>
> <a href="mailto:openal@openal.org">openal@openal.org</a><br>
> <a href="http://openal.org/mailman/listinfo/openal" target="_blank">http://openal.org/mailman/listinfo/openal</a><br>
<br>
<br>
_______________________________________________<br>
openal mailing list<br>
<a href="mailto:openal@openal.org">openal@openal.org</a><br>
<a href="http://openal.org/mailman/listinfo/openal" target="_blank">http://openal.org/mailman/listinfo/openal</a><br>
</div></div></blockquote></div><br></div>