#64
- Created on2007-12-18 02:42
- Reported by
- StatusFixed
- PriorityNormal (3)
- Assigned to
- Milestone-
- Plan Level-
- Due Date-
error opening multiple streams on the same device
When I try to open multiple output streams simultaneously with the same device, I get an error in this call:
#if 0
/* -- add listener for dropouts -- */
ERR_WRAP( AudioDeviceAddPropertyListener( *audioDevice,
0,
outStreamParams ? false : true,
kAudioDeviceProcessorOverload,
xrunCallback,
(void *)stream) );
#endif
which apparently was a fairly recent addition. With that code commented out, I can open multiple simultaneous streams and they mix perfectly.
#if 0
/* -- add listener for dropouts -- */
ERR_WRAP( AudioDeviceAddPropertyListener( *audioDevice,
0,
outStreamParams ? false : true,
kAudioDeviceProcessorOverload,
xrunCallback,
(void *)stream) );
#endif
which apparently was a fairly recent addition. With that code commented out, I can open multiple simultaneous streams and they mix perfectly.
Leave a comment
on 2007-12-18 02:44 *
By bejayoharen
The issue here is probably that coreAudio doesn't like having the same listener applied multiple times to the same device. A check will have to be added for that and some sort of multiplexing will be needed so each stream can be notified of xrun conditions when they are detected.
on 2008-01-13 01:14 *
By bejayoharen
Brenton Partridge asked:
More long-term, not knowing that much about the CoreAudio code, could we just add the dropout
listener for the first stream opened to the device, and automatically not listen for dropouts on
subsequent streams to the device?
To which I replied:
If you think about it for a moment the problem is a bit more complex. Say the user opens a stream on device 1. Okay, so PortAudio puts a listener on device 1. Next, say the user opens another stream on device 1. At this point, we can't add another listener to device 1, because the OS will get upset (That's the error everyone's seeing). We have to keep track ourselves. Now if the user closes a stream, we have to know how many streams are left on a given device, so that when the last stream on a given device is closed we can stop listening, so we don't get spurious messages about a device under/overrunning. Also, we need to make sure that our one listener per device manages to distribute xrun messages to all streams that are using the device, because that is what the API calls for. A simple linked list or resizable array will solve the issue, I think, but it'll take time to write it and test it. This is not a feature that seems critical to anyone -- especially with an easy workaround when it causes real problems -- so I haven't made it a priority. Again, I'm happy to accept patches.
More long-term, not knowing that much about the CoreAudio code, could we just add the dropout
listener for the first stream opened to the device, and automatically not listen for dropouts on
subsequent streams to the device?
To which I replied:
If you think about it for a moment the problem is a bit more complex. Say the user opens a stream on device 1. Okay, so PortAudio puts a listener on device 1. Next, say the user opens another stream on device 1. At this point, we can't add another listener to device 1, because the OS will get upset (That's the error everyone's seeing). We have to keep track ourselves. Now if the user closes a stream, we have to know how many streams are left on a given device, so that when the last stream on a given device is closed we can stop listening, so we don't get spurious messages about a device under/overrunning. Also, we need to make sure that our one listener per device manages to distribute xrun messages to all streams that are using the device, because that is what the API calls for. A simple linked list or resizable array will solve the issue, I think, but it'll take time to write it and test it. This is not a feature that seems critical to anyone -- especially with an easy workaround when it causes real problems -- so I haven't made it a priority. Again, I'm happy to accept patches.
on 2008-01-24 07:44 *
By bejayoharen
Should be fixed in revision 1316, though still needs thorough testing.
