From ian_minett at creativelabs.com Mon Feb 6 14:53:03 2012 From: ian_minett at creativelabs.com (Ian Minett) Date: Mon Feb 6 14:54:19 2012 Subject: [Openal-devel] Test Message (resend) - eom Message-ID: Hi, this is a test message for the OpenAL mailing lists, please ignore. - Ian 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. This email is for communication purposes only. It is not intended to constitute an offer or form a binding agreement. Our company accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided. If you have received this message in error, please delete it and contact the sender immediately. Thank you. From chris.kcat at gmail.com Wed Feb 15 14:14:16 2012 From: chris.kcat at gmail.com (Chris Robinson) Date: Wed Feb 15 14:14:05 2012 Subject: [Openal-devel] Loopback API design question Message-ID: <6302119.it8nLv55LX@kittycat> Hi guys. I'm more or less finished with the loopback API and am in the process of writing up an extension spec for it, but there's a relatively minor issue I'd like to get feedback on. Currently, a loopback device is created with this function: ALCdevice* ALC_APIENTRY alcLoopbackOpenDeviceSOFT(void); This works well enough as it is, however it wouldn't be able to work if implemented in a router DLL as there's no informtation given by the app to specify which driver to send the call to. There's a few ways I can think of to handle this: 1) Have the function take a string as a parameter so it can tell what driver to call to ("OpenAL Soft", "Rapture3D", "Generic Software", etc). Problem here is there's no way to query the available drivers, and another enumeration doesn't sound very nice. Matching a device driver to an open device could be a problem too. 2) Have it take a string, but accept the same strings as device enumeration. This would allow an app to get the right driver by providing the name of an already-open device, but it feels rather hacky as its not really opening the specified device. 3) Have it take an ALCdevice* handle. This would allow apps to easily match a loopback device with a device driver, but it would also require an open playback device if you want a specific driver. For all three cases, NULL could be passed to take a default. I think I would prefer 3 personally, but what do you guys think? Only other option is to not do anything and essentially require the app to use an open device to call alcGetProcAddress with to get the exports directly from a specific driver. I don't like this as it would also require getting all ALC and AL functions used with the loopback device (since the device handle returned by a driver-specific OpenDevice function won't be recognized outside of that driver), but it is an option. From jdaly at ist.ucf.edu Wed Feb 15 15:10:29 2012 From: jdaly at ist.ucf.edu (Jason Daly) Date: Wed Feb 15 15:10:46 2012 Subject: [Openal-devel] Loopback API design question In-Reply-To: <6302119.it8nLv55LX@kittycat> References: <6302119.it8nLv55LX@kittycat> Message-ID: <4F3C3B65.80908@ist.ucf.edu> Hi, Chris, On 02/15/2012 05:14 PM, Chris Robinson wrote: > For all three cases, NULL could be passed to take a default. I think I would > prefer 3 personally, but what do you guys think? Of the choices, I like 3 the best as well. An opaque pointer is less error-prone than passing strings around. It has a nice symmetry to it, too (open a loopback device from "this" device). Having to open a playback device is a small price to pay. The only other viable option to me is another enumeration extension for loopback devices (as you alluded to in option 1). Are you planning on updating the router DLL with this extension, too? --"J" From chris.kcat at gmail.com Wed Feb 15 15:52:49 2012 From: chris.kcat at gmail.com (Chris Robinson) Date: Wed Feb 15 15:52:51 2012 Subject: [Openal-devel] Loopback API design question In-Reply-To: <4F3C3B65.80908@ist.ucf.edu> References: <6302119.it8nLv55LX@kittycat> <4F3C3B65.80908@ist.ucf.edu> Message-ID: <4570123.Knz9ryxceZ@kittycat> On Wednesday, February 15, 2012 6:10:29 PM Jason Daly wrote: > Are you planning on updating the router DLL with this extension, too? If Creative would accept such a patch, yeah. Or if not, maybe I'll make an updated version of it to distribute with OpenAL Soft's binary package. The thread-local context extension could also benefit from support in the router. From chris.kcat at gmail.com Thu Feb 16 00:22:42 2012 From: chris.kcat at gmail.com (Chris Robinson) Date: Thu Feb 16 00:22:27 2012 Subject: [Openal-devel] Loopback API design question In-Reply-To: <4F3C3B65.80908@ist.ucf.edu> References: <6302119.it8nLv55LX@kittycat> <4F3C3B65.80908@ist.ucf.edu> Message-ID: <2388590.KJn12fenS1@kittycat> Here's a first draft of the extension spec. I'm unsure whether to call it ALC_SOFT_loopback_device or ALC_SOFT_loopback... loopback_device sounds a bit more "natural", but loopback fits better with the capture extension which is called CAPTURE, not CAPTURE_DEVICE. I'm leaning towards ALC_SOFT_loopback. If there's any questions on how to use it, feel free to ask and I'll try to explain or clarify. If there's any problem with the wording, let me know and I'll try to fix it up. Thanks. :) Name ALC_SOFT_loopback Contributors Chris Robinson Contact Chris Robinson (chris.kcat 'at' gmail.com) Status In-progress Dependencies This extension is written against the OpenAL 1.1 specification. Overview This extension allows an application to read back OpenAL's rendered audio instead of having it output to an audio device on the system. Unextended OpenAL will output audio to an audio device, with no mechanism to allow an application to divert the audio somewhere else. Issues Q: How are loopback devices created and handled? A: Loopback devices are created using the alcLoopbackOpenDeviceSOFT function. They are closed using the standard alcCloseDevice function. Note that since alcLoopbackOpenDeviceSOFT is a driver-specific export and returns a driver-specific device handle, the ALC and AL functions used with such a device must come from the same driver. Q: How is the device's render format specified? A: By passing ALC_FORMAT_CHANNELS_SOFT, ALC_FORMAT_TYPE_SOFT, and ALC_FREQUENCY attributes when creating a context. If more than one context is created, the device will use the last format specified. It is also considered an error to create a context without specifying all three attributes. Q: Does the device update automatically over time? A: No. The speed of rendering is controlled entirely by the app, so the faster the app calls to render audio, the faster the device's (and subsequently, source's and buffer's) state progresses. This allows an app to, for example, render an audio mix to encode with a video without having to wait the amount of time it would take to actually play. Q: Are all context attributes supported with loopback devices? A: All standard ones except for ALC_SYNC and ALC_REFRESH. The precise meaning of ALC_SYNC is not well defined for this situation, and the refresh rate is controlled by the app to be as fast or slow as it wants. New Procedures and Functions ALCdevice* alcLoopbackOpenDeviceSOFT(ALCdevice *device); ALCboolean alcIsRenderFormatSupportedSOFT(ALCdevice *device, ALCsizei frequency, ALCenum channels, ALCenum type); void alcRenderSamplesSOFT(ALCdevice *device, ALCvoid *buffer, ALCsizei samples); New Tokens Accepted by the parameter of alcIsRenderFormatSupportedSOFT: ALC_BYTE_SOFT 0x1400 ALC_UNSIGNED_BYTE_SOFT 0x1401 ALC_SHORT_SOFT 0x1402 ALC_UNSIGNED_SHORT_SOFT 0x1403 ALC_INT_SOFT 0x1404 ALC_UNSIGNED_INT_SOFT 0x1405 ALC_FLOAT_SOFT 0x1406 Accepted by the parameter of alcIsRenderFormatSupportedSOFT: ALC_MONO_SOFT 0x1500 ALC_STEREO_SOFT 0x1501 ALC_QUAD_SOFT 0x1503 ALC_5POINT1_SOFT 0x1504 ALC_6POINT1_SOFT 0x1505 ALC_7POINT1_SOFT 0x1506 Accepted as part of the parameter of alcCreateContext: ALC_FORMAT_CHANNELS_SOFT 0x1990 ALC_FORMAT_TYPE_SOFT 0x1991 Additions to Specification Loopback Devices Loopback devices provide a way for applications to "read back" rendered audio without it being sent to an actual audio device. It allows applications to render audio as fast or slow as it needs, making it suitable for non-real-time rendering, and so it can be passed to an audio codec or something for further processing. To open a loopback device, use the function ALCdevice* alcLoopbackOpenDeviceSOFT(ALCdevice *device); The device parameter is used to tell the AL which device or device driver to use for subsequent rendering. This may be NULL for an implementation- defined default, otherwise it must be a valid device handle. A loopback device behaves largely the same as a playback device. You may query playback state and error codes, and create contexts, which can then be set as current to generate sources and buffers like normal. Note that loopback devices do not have either the ALC_SYNC or ALC_REFRESH attributes. Attempting to query them will result in an ALC_INVALID_ENUM error. When creating contexts, the attribute list must specify the format used for rendering. This is done with the ALC_FORMAT_CHANNELS_SOFT, ALC_FORMAT_TYPE_SOFT, and ALC_FREQUENCY attributes. This controls the format of the audio subsequently rendered by the device. To check if a particular rendering format is available, use the function ALCboolean alcIsRenderFormatSupportedSOFT(ALCdevice *device, ALCsizei frequency, ALCenum channels, ALCenum type); The handle is the loopback device to query, and , which must be a positive non-zero number, is the sample rate of the rendered audio. is the channel configuration used for rendering (see Table 1.0), and is the sample type of the written audio (see Table 1.1). Table 1.0. Channel configurations Channels Configuration Order ---------------- ------------- ----------------------------------------- ALC_MONO_SOFT Mono mono ALC_STEREO_SOFT Stereo front-left, front-right ALC_QUAD_SOFT Quad front-left, front-right, rear-left, rear-right ALC_5POINT1_SOFT 5.1 front-left, front-right, front-center, lfe, rear-left, rear-right ALC_6POINT1_SOFT 6.1 front-left, front-right, front-center, lfe, rear-center, side-left, side-right ALC_7POINT1_SOFT 7.1 front-left, front-right, front-center, lfe, rear-left, rear-right, side-left, side-right Valid channel configurations. The channel order is the order which interleaved samples will be written to an output buffer. Table 1.1. Sample types Type Data type Nominal value range ----------------------- --------- ------------------------- ALC_BYTE_SOFT ALCbyte -128...+127 ALC_UNSIGNED_BYTE_SOFT ALCubyte 0...+255 ALC_SHORT_SOFT ALCshort -32768...+32767 ALC_UNSIGNED_SHORT_SOFT ALCushort 0...+65535 ALC_INT_SOFT ALCint -2147483648...+2147483647 ALC_UNSIGNED_INT_SOFT ALCuint 0...+4294967295 ALC_FLOAT_SOFT ALCfloat -1.0...+1.0 Data types and value ranges of renderable sample types. These values are normalized, meaning the ALCubyte range of 0...255 corresponds to the same range as ALCshort's -32768...+32767. ALCfloat samples may specify values outside of their nominal range. The state of various objects on loopback devices (including processed buffers and source offsets) is processed only when new samples are rendered. To render samples, use the function void alcRenderSamplesSOFT(ALCdevice *device, ALCvoid *buffer, ALCsizei samples); The specified is the loopback device which samples are rendered from, using its contexts and associated buffers and sources. The number of sample frames to render is specified by , which is then written to . Errors An ALC_INVALID_VALUE error is generated if alcCreateContext is called without a valid format specified. An ALC_INVALID_ENUM error is generated if alcCreateContext is called with an unsupported channel configuration or sample type. An ALC_INVALID_VALUE error is generated if alcIsRenderFormatSupportedSOFT is called with a zero or negative value for . An ALC_INVALID_ENUM error is generated if alcIsRenderFormatSupportedSOFT is called with an unsupported channel configuration or sample type. An ALC_INVALID_DEVICE error is generated if alcLoopbackOpenDeviceSOFT is called with an invalid device handle. An ALC_INVALID_DEVICE error is generated if alcRenderSamplesSOFT or alcIsRenderFormatSupportedSOFT is called with a device handle not created by alcLoopbackOpenDeviceSOFT. From chris.kcat at gmail.com Mon Feb 20 12:41:58 2012 From: chris.kcat at gmail.com (Chris Robinson) Date: Mon Feb 20 12:41:23 2012 Subject: [Openal-devel] PulseAudio backend troubles Message-ID: <4734190.StdWTiBpyq@kittycat> Hi guys, I have a bit of a query. Currently, OpenAL Soft will prefer the PulseAudio backend when it's available. However, lately I've noticed that I end up getting a lot of breakup in playback when the PA server has been running for a while. Traces I've done have shown that Pulse is not running out of audio -- initial startup has it filling the whole buffer, and each update after correctly shows an approximate period-sized writable chunk which is only a fraction of the whole buffer. I've also notced that the ALSA->Pulse bridge seems to be working much better. I no longer have to explicitly disable mmap as it appears ALSA's mmap emulation is now off by default (it would break the pulse plugin when used), and audio playback doesn't break up. I've been considering dropping, or at least lowering the priority of, the PulseAudio backend in favor of the ALSA backend. However, I'm not sure if the mmap emulation bug is truly gone or if it's just my system and/or newer setups that work now. Also, the ALSA backend doesn't do as good of a job autodetecting the default output mode (eg, quad or 5.1 surround) like the PulseAudio backend does, especially with the pulse plugin (even without 'plug', it'll accept any output mode). So, I have a quandry. Do I leave the PulseAudio backend as it is, where it breaks when PulseAudio's minimum latency starts growing high (as it often likes to do)? Or do I lower its priority to prefer the ALSA backend and the pulse plugin, which doesn't do as good of a job in detecting the default audio config and may still have mmap issues for some people? Unless someone can take a look at OpenAL Soft's PulseAudio backend, I can't see anything that should be causing the breakup in playback as it's not underrunning. Of course when PulseAudio's minimum latency grows you'll start having a lot of audio lag anyway, which is bad either way I take it, and there's nothing OpenAL Soft can do for that (requires killing and restarting the pulse server to fix). Any ideas or suggestions? From m.b.lankhorst at gmail.com Tue Feb 21 08:25:43 2012 From: m.b.lankhorst at gmail.com (Maarten Lankhorst) Date: Tue Feb 21 08:26:00 2012 Subject: [Openal-devel] PulseAudio backend troubles In-Reply-To: <4734190.StdWTiBpyq@kittycat> References: <4734190.StdWTiBpyq@kittycat> Message-ID: <4F43C587.3030800@gmail.com> Hey Chris, Op 20-02-12 21:41, Chris Robinson schreef: > Hi guys, I have a bit of a query. > > Currently, OpenAL Soft will prefer the PulseAudio backend when it's available. > However, lately I've noticed that I end up getting a lot of breakup in > playback when the PA server has been running for a while. Traces I've done > have shown that Pulse is not running out of audio -- initial startup has it > filling the whole buffer, and each update after correctly shows an approximate > period-sized writable chunk which is only a fraction of the whole buffer. > > I've also notced that the ALSA->Pulse bridge seems to be working much better. > I no longer have to explicitly disable mmap as it appears ALSA's mmap > emulation is now off by default (it would break the pulse plugin when used), > and audio playback doesn't break up. > > I've been considering dropping, or at least lowering the priority of, the > PulseAudio backend in favor of the ALSA backend. However, I'm not sure if the > mmap emulation bug is truly gone or if it's just my system and/or newer setups > that work now. Also, the ALSA backend doesn't do as good of a job > autodetecting the default output mode (eg, quad or 5.1 surround) like the > PulseAudio backend does, especially with the pulse plugin (even without > 'plug', it'll accept any output mode). > > > So, I have a quandry. Do I leave the PulseAudio backend as it is, where it > breaks when PulseAudio's minimum latency starts growing high (as it often > likes to do)? Or do I lower its priority to prefer the ALSA backend and the > pulse plugin, which doesn't do as good of a job in detecting the default audio > config and may still have mmap issues for some people? > > Unless someone can take a look at OpenAL Soft's PulseAudio backend, I can't > see anything that should be causing the breakup in playback as it's not > underrunning. Of course when PulseAudio's minimum latency grows you'll start > having a lot of audio lag anyway, which is bad either way I take it, and > there's nothing OpenAL Soft can do for that (requires killing and restarting > the pulse server to fix). > Could you try this? I follow the same thing you're doing in the alsa backend.. make tlength at least 100ms, which might help with underruns. This should be the same as you're doing with alsa->pulseaudio . I suppose the max latency doesn't matter much as you will never fill up to tlength in this case. diff --git a/Alc/backends/pulseaudio.c b/Alc/backends/pulseaudio.c index b8a7aa5..1861c50 100644 --- a/Alc/backends/pulseaudio.c +++ b/Alc/backends/pulseaudio.c @@ -641,19 +641,22 @@ static ALuint PulseProc(ALvoid *param) { ALCdevice *Device = param; pulse_data *data = Device->ExtraData; - ssize_t len; + ssize_t len, used, fill; SetRTPriority(); pa_threaded_mainloop_lock(data->loop); do { + fill = Device->NumUpdates * Device->UpdateSize * data->frame_size; + len = (Device->Connected ? pa_stream_writable_size(data->stream) : 0); - len -= len%(Device->UpdateSize*data->frame_size); - if(len == 0) + used = data->attr.tlength - len; + if(used >= fill) { pa_threaded_mainloop_wait(data->loop); continue; } + len = fill - used; while(len > 0) { @@ -934,7 +937,9 @@ static ALCboolean pulse_reset_playback(ALCdevice *device) //{{{ data->attr.prebuf = -1; data->attr.fragsize = -1; data->attr.minreq = device->UpdateSize * data->frame_size; - data->attr.tlength = data->attr.minreq * maxu(device->NumUpdates, 2); + data->attr.tlength = maxu(device->UpdateSize*device->NumUpdates, + 100*device->Frequency/1000); + data->attr.tlength *= data->frame_size; data->attr.maxlength = -1; flags |= PA_STREAM_EARLY_REQUESTS; flags |= PA_STREAM_INTERPOLATE_TIMING | PA_STREAM_AUTO_TIMING_UPDATE; @@ -993,8 +998,8 @@ static ALCboolean pulse_reset_playback(ALCdevice *device) //{{{ * accordingly. */ data->attr.minreq = (ALuint64)(data->attr.minreq/data->frame_size) * data->spec.rate / device->Frequency * data->frame_size; - data->attr.tlength = data->attr.minreq * maxu(device->NumUpdates, 2); - + data->attr.tlength = maxu(data->attr.minreq * device->NumUpdates, + data->frame_size * 100 * data->spec.rate / 1000); o = pa_stream_set_buffer_attr(data->stream, &data->attr, stream_success_callback, device); while(pa_operation_get_state(o) == PA_OPERATION_RUNNING) @@ -1014,7 +1019,7 @@ static ALCboolean pulse_reset_playback(ALCdevice *device) //{{{ data->attr = *(pa_stream_get_buffer_attr(data->stream)); device->UpdateSize = data->attr.minreq / data->frame_size; - device->NumUpdates = (data->attr.tlength/data->frame_size) / device->UpdateSize; + device->NumUpdates = minu(device->NumUpdates, (data->attr.tlength/data->frame_size) / device->UpdateSize); if(device->NumUpdates <= 1) { pa_operation *o; From chris.kcat at gmail.com Tue Feb 21 12:34:11 2012 From: chris.kcat at gmail.com (Chris Robinson) Date: Tue Feb 21 12:33:30 2012 Subject: [Openal-devel] PulseAudio backend troubles In-Reply-To: <4F43C587.3030800@gmail.com> References: <4734190.StdWTiBpyq@kittycat> <4F43C587.3030800@gmail.com> Message-ID: <1333098.p4BWDtz8Yc@kittycat> On Tuesday, February 21, 2012 5:25:43 PM Maarten Lankhorst wrote: > Could you try this? > > I follow the same thing you're doing in the alsa backend.. make tlength at > least 100ms, which might help with underruns. This should be the same as > you're doing with alsa->pulseaudio . I suppose the max latency doesn't > matter much as you will never fill up to tlength in this case. Hi. I'm not sure this will work properly. With PA_STREAM_EARLY_REQUESTS, PulseAudio will send a write request when 'minreq' bytes are writeable in the stream, however this wouldn't account for the extra space that OpenAL Soft would have no intention of filling. So the write request would get signaled before a full update is ready. Additionally, the default buffer metrics are 1024-sample updates with 4 updates at 44100hz, which comes out to 92.8ms, which is already close to 100ms (and frankly is already on the high side, but is chosen to try and avoid underruns for weaker machines). PulseAudio doesn't even like it this big and hiccups on occasion, trying to make it bigger. However with ALSA's dmix, I can halve it (ie, 4 512-sample updates) and still run perfectly. After just a day of the pulse server running, PA will turn my 1024x4 request into 2910x3, which is nearly 200ms. PulseAudio still runs smooth enough with this (needs to get higher before starting to break up), but the latency is way too high for my liking. FWIW, the alsa->pulse plugin reports that it gives me the requested 1024x4 buffer, but the audible delay tells a much different story. From erik at ehofman.com Tue Feb 28 01:17:54 2012 From: erik at ehofman.com (Erik Hofman) Date: Tue Feb 28 01:17:59 2012 Subject: [Openal-devel] Loopback API design question In-Reply-To: <2388590.KJn12fenS1@kittycat> References: <6302119.it8nLv55LX@kittycat> <4F3C3B65.80908@ist.ucf.edu> <2388590.KJn12fenS1@kittycat> Message-ID: <1330420674.15575.8.camel@Raptor> On Thu, 2012-02-16 at 00:22 -0800, Chris Robinson wrote: > Here's a first draft of the extension spec. I'm unsure whether to call it > ALC_SOFT_loopback_device or ALC_SOFT_loopback... loopback_device sounds a bit > more "natural", but loopback fits better with the capture extension which is > called CAPTURE, not CAPTURE_DEVICE. I'm leaning towards ALC_SOFT_loopback. May I propose a different approach that I have been tinkering with? The idea is to have a device opened using the normal alcOpen calls, set it up using the normal alcContext calls and use that device-handle for the alcCaptureStart/Stop and alcCaptureSamples functions (note: there is no call to alcCaptureOpen/Close in the case of a loopback device) The way I see it this reuses most of the code that is already available but it lacks some control (specifying the requested format for example). It might therefore be necessary to add alcCapture[GS]etIntegerv functions that also allows to check if an opened device is actually capable of functioning as a loopback device. I would also propose that at least one device is available that has "Loopback" in it's name (or maybe demand a sole "Loopback" devicename). Erik From chris.kcat at gmail.com Tue Feb 28 03:26:35 2012 From: chris.kcat at gmail.com (Chris Robinson) Date: Tue Feb 28 03:25:19 2012 Subject: [Openal-devel] Loopback API design question In-Reply-To: <1330420674.15575.8.camel@Raptor> References: <6302119.it8nLv55LX@kittycat> <2388590.KJn12fenS1@kittycat> <1330420674.15575.8.camel@Raptor> Message-ID: <2390471.ObvMA6gOWu@kittycat> On Tuesday, February 28, 2012 10:17:54 AM Erik Hofman wrote: > The idea is to have a device opened using the normal alcOpen calls, set > it up using the normal alcContext calls and use that device-handle for > the alcCaptureStart/Stop and alcCaptureSamples functions (note: there is > no call to alcCaptureOpen/Close in the case of a loopback device) > > The way I see it this reuses most of the code that is already available > but it lacks some control (specifying the requested format for example). > It might therefore be necessary to add alcCapture[GS]etIntegerv > functions that also allows to check if an opened device is actually > capable of functioning as a loopback device. > > I would also propose that at least one device is available that has > "Loopback" in it's name (or maybe demand a sole "Loopback" devicename). The idea here is that it would allow an application to render the audio at its own pace and write it out to where it wants. This could, for example, be as fast as possible to an audio codec (to compress to an on-disk file or something), or to its own audio device at the device's speed (if it can't or doesn't want to use OpenAL's device handling for some reason). If the application has to have an output device open, then has to wait for audio to be generated before it can do anything with it, it wouldn't work as well for that purpose. What you're suggesting sounds closer to the foldback extension: http://icculus.org/alextreg/wiki/AL_EXT_FOLDBACK except at the device level instead of the context level, and using the capture functions instead of a callback. Something like that might be useful to have, but I think it should be separate. From erik at ehofman.com Tue Feb 28 06:47:12 2012 From: erik at ehofman.com (Erik Hofman) Date: Tue Feb 28 06:47:16 2012 Subject: [Openal-devel] Loopback API design question In-Reply-To: <2390471.ObvMA6gOWu@kittycat> References: <6302119.it8nLv55LX@kittycat> <2388590.KJn12fenS1@kittycat> <1330420674.15575.8.camel@Raptor> <2390471.ObvMA6gOWu@kittycat> Message-ID: <1330440433.24529.4.camel@Raptor> On Tue, 2012-02-28 at 03:26 -0800, Chris Robinson wrote: > The idea here is that it would allow an application to render the audio at its > own pace and write it out to where it wants. This could, for example, be as > fast as possible to an audio codec (to compress to an on-disk file or > something), or to its own audio device at the device's speed (if it can't or > doesn't want to use OpenAL's device handling for some reason). I think that specifying ALC_REFRESH to 0 to be ast fast as possible would solve this problem. > If the application has to have an output device open, then has to wait for > audio to be generated before it can do anything with it, it wouldn't work as > well for that purpose. In your proposal the caller will also have to wait for the data to be available in alcRenderSamplesSOFT. To me both implementations are not mutually exclusive in that one would provide more functionality over the other. I just think that using the alcCapture functions would be a bit cleaner. Erik From chris.kcat at gmail.com Wed Feb 29 01:31:14 2012 From: chris.kcat at gmail.com (Chris Robinson) Date: Wed Feb 29 01:29:52 2012 Subject: [Openal-devel] Loopback API design question In-Reply-To: <1330440433.24529.4.camel@Raptor> References: <6302119.it8nLv55LX@kittycat> <2390471.ObvMA6gOWu@kittycat> <1330440433.24529.4.camel@Raptor> Message-ID: <24640945.kamnHFAqXd@kittycat> On Tuesday, February 28, 2012 3:47:12 PM Erik Hofman wrote: > I think that specifying ALC_REFRESH to 0 to be ast fast as possible > would solve this problem. How would it be limited so the app doesn't miss anything? And this seems to still require using a "real" playback device. > > If the application has to have an output device open, then has to wait for > > audio to be generated before it can do anything with it, it wouldn't work > > as well for that purpose. > > In your proposal the caller will also have to wait for the data to be > available in alcRenderSamplesSOFT. alcRenderSamplesSOFT renders the samples itself. The app doesn't have to wait before getting any number of samples from it. > To me both implementations are not mutually exclusive in that one would > provide more functionality over the other. I just think that using the > alcCapture functions would be a bit cleaner. Using the capture functions for foldback-like functionality would make sense, and probably something to consider for another extension. But it doesn't make sense to me to use them for on-demand rendering since it's rendering samples, not capturing them. From erik at ehofman.com Wed Feb 29 01:43:17 2012 From: erik at ehofman.com (Erik Hofman) Date: Wed Feb 29 01:43:20 2012 Subject: [Openal-devel] Loopback API design question In-Reply-To: <24640945.kamnHFAqXd@kittycat> References: <6302119.it8nLv55LX@kittycat> <2390471.ObvMA6gOWu@kittycat> <1330440433.24529.4.camel@Raptor> <24640945.kamnHFAqXd@kittycat> Message-ID: <1330508597.10047.7.camel@Raptor> On Wed, 2012-02-29 at 01:31 -0800, Chris Robinson wrote: > On Tuesday, February 28, 2012 3:47:12 PM Erik Hofman wrote: > > I think that specifying ALC_REFRESH to 0 to be ast fast as possible > > would solve this problem. > > How would it be limited so the app doesn't miss anything? And this seems to > still require using a "real" playback device. The way I envision this is that setting refresh disables real-time rendering (I could live with another way of telling the library to do so). This way the rendering step is triggered when calling the alcCaptureSamples function, just prior to returning the data. This would indeed require a device, being it a software renderer or a hardware accelerated one. In both cases it's just a matter of rendering up to the point the data is sent to the physical device and then instead of doing so returning the processed data to the caller application. > > > > If the application has to have an output device open, then has to wait for > > > audio to be generated before it can do anything with it, it wouldn't work > > > as well for that purpose. > > > > In your proposal the caller will also have to wait for the data to be > > available in alcRenderSamplesSOFT. > > alcRenderSamplesSOFT renders the samples itself. The app doesn't have to wait > before getting any number of samples from it. Alright, but there is a bit of waiting involved until the data is processed. > > To me both implementations are not mutually exclusive in that one would > > provide more functionality over the other. I just think that using the > > alcCapture functions would be a bit cleaner. > > Using the capture functions for foldback-like functionality would make sense, > and probably something to consider for another extension. But it doesn't make > sense to me to use them for on-demand rendering since it's rendering samples, > not capturing them. That depends on the way you define capture I guess. The extension not recording any samples but I would argue that retrieving samples from the rendering stage classifies as capturing. Erik