ah yeah I sure can. well beside the fixed block size there are the following requirements:
I've been thinking about the fixed block size and was considering adding it back before release 1.3. Not that it will be of any use for you right now, but maybe someone in the future will have the same requirement! ^^
I've been toying a bit with various sound transformations and I'll probably spend some time toying with things based on Sylvain Marchand's work (he was one of my teachers during my last year of master, 10 years ago): http://dept-info.labri.u-bordeaux.fr/~sm/Publications/
well most importantly: I would like the playback and the capturing to stay in sync.none
Can you elaborate a bit more on this point? But I'm already sensing it's not an easy things to do with OpenAL.
[*]information about how big the latency actually is, meaning at what time can I expect the current sample to be played back and accordingly on what exact time were the samples captured exactlynone
For the capturing, your system of timestamps should have worked just fine, however I don't think you can accurately predict when the buffers sent by OpenAL will reach the sound card. If I remember correctly, that was also part of a big rant from Jonathan Blow when discussing a port of Braid for linux on his blog.
[*]synchronization between the visual stuff and the audio -> relying on the same clock
none
That isn't a big deal as visuals will react immediately (that is within the same frame, which should be more than enough for human perception, unless you're running at 10 FPS ).
ok my project is really time critical and I guess this are very specifc requirements that normal games won't have.
I completely switched to portaudio now. all the above is doable with this library. things just got a bit more complicated then "orxSound_Play(...)"^^
I guess the current API is sufficient for most games.
I'm glad you found a working solution with PortAudio. Too bad orx didn't fit your requirements, maybe with a future version?
However I'm always willing to improve orx use while trying to keep things as simple as possible for most of the "usual" needs. That being said, writing a PortAudio based plugin and/or extending features through the use of events, which are less intruding than direct API changes, is something that could totally happen and I'd be happy to work in this direction.
I will write how the whole thing works using portaudio, maybe it will then become a bit clearer what I ment then: iarwain wrote:
tdomhan wrote:
ah yeah I sure can. well beside the fixed block size there are the following requirements:
I've been thinking about the fixed block size and was considering adding it back before release 1.3. Not that it will be of any use for you right now, but maybe someone in the future will have the same requirement! ^^
I've been toying a bit with various sound transformations and I'll probably spend some time toying with things based on Sylvain Marchand's work (he was one of my teachers during my last year of master, 10 years ago): http://dept-info.labri.u-bordeaux.fr/~sm/Publications/
well most importantly: I would like the playback and the capturing to stay in sync.none
Can you elaborate a bit more on this point? But I'm already sensing it's not an easy things to do with OpenAL.
So in portaudio it works like this: You first register a callback that will be called each time the audio hardware needs new data. the buffers will be created by portaudio. the callback will be called from some fancy high priority/low level audio thread. if I understood it correctly it will be triggered/called from some audio hardware interrupt. the result is that you may not allocate memory and do any disk IO. the upside is that it will even be called if the game itself lags/halts etc.
The important thing is that there is only one callback for the input and the output. this means both use the same clock for the timestamps. furthermore there will be as much samples available from as an input as there are for the output, e.g. if you said you will always want 4096 samples then for each time the callback is called you have to fill the output buffer with 4096 samples and you can fetch 4096 samples from the input buffer.
[*]information about how big the latency actually is, meaning at what time can I expect the current sample to be played back and accordingly on what exact time were the samples captured exactlynone
For the capturing, your system of timestamps should have worked just fine, however I don't think you can accurately predict when the buffers sent by OpenAL will reach the sound card. If I remember correctly, that was also part of a big rant from Jonathan Blow when discussing a port of Braid for linux on his blog.
yep I didn't find a way to determine the latency in OpenAL. portaudio tries to estimate the latency. but depending on the host API that is being used this estimate might not be very accurate.
[*]synchronization between the visual stuff and the audio -> relying on the same clock
none
That isn't a big deal as visuals will react immediately (that is within the same frame, which should be more than enough for human perception, unless you're running at 10 FPS ).
hehe, yeah that is actually the problem, it is too fast!!
for example in my game I have a background sound. now let's say I would like to have some audio effects as soons as a specific part of the background sound is currently played. because of all the buffering the background music will not be played back as soon as the output buffer is filled but probably several hundret milli seconds later. so I have to delay the visuals by exactly the time. otherwise you would first see the specific effect and then after XY milli seconds you would hear the sound.
but in order to do that you need to rely on the same clock andsome information about the output latency.
similar stuff is true for the input.
ok my project is really time critical and I guess this are very specifc requirements that normal games won't have.
I completely switched to portaudio now. all the above is doable with this library. things just got a bit more complicated then "orxSound_Play(...)"^^
I guess the current API is sufficient for most games.
I'm glad you found a working solution with PortAudio. Too bad orx didn't fit your requirements, maybe with a future version?
However I'm always willing to improve orx use while trying to keep things as simple as possible for most of the "usual" needs. That being said, writing a PortAudio based plugin and/or extending features through the use of events, which are less intruding than direct API changes, is something that could totally happen and I'd be happy to work in this direction.
I will write how the whole thing works using portaudio, maybe it will then become a bit clearer what I ment then:[...]
So in portaudio it works like this: You first register a callback that will be called each time the audio hardware needs new data. the buffers will be created by portaudio. the callback will be called from some fancy high priority/low level audio thread. if I understood it correctly it will be triggered/called from some audio hardware interrupt. the result is that you may not allocate memory and do any disk IO. the upside is that it will even be called if the game itself lags/halts etc.
I think it might be the same hardware-interrupt way of working for non-software versions of OpenAL.
The important thing is that there is only one callback for the input and the output. this means both use the same clock for the timestamps. furthermore there will be as much samples available from as an input as there are for the output, e.g. if you said you will always want 4096 samples then for each time the callback is called you have to fill the output buffer with 4096 samples and you can fetch 4096 samples from the input buffer.
Thanks for the details! That's very helpful. Currently sound input/output is on the same clock in orx, but not on the same ticks. It's easy to change so I'll do it tonight and make sure that if a recording callback is called it'll always be synchronized with any input buffering.
hehe, yeah that is actually the problem, it is too fast!!
for example in my game I have a background sound. now let's say I would like to have some audio effects as soons as a specific part of the background sound is currently played. because of all the buffering the background music will not be played back as soon as the output buffer is filled but probably several hundret milli seconds later. so I have to delay the visuals by exactly the time. otherwise you would first see the specific effect and then after XY milli seconds you would hear the sound.
Ok, now I understand better your issue. I guess that by modifying the numbers of buffers and their size we should be able to obtain a similar result. I could expose those in the config system when one needs other values than the "safe" default ones.
If you'd like to give it a try, I'd be happy to make such changes. Even if it's no use anymore for you, it'd be so as to see if orx could achieve similar results for projects that are very demanding on sound synchronization.
Comments
I've been thinking about the fixed block size and was considering adding it back before release 1.3. Not that it will be of any use for you right now, but maybe someone in the future will have the same requirement! ^^
I've been toying a bit with various sound transformations and I'll probably spend some time toying with things based on Sylvain Marchand's work (he was one of my teachers during my last year of master, 10 years ago): http://dept-info.labri.u-bordeaux.fr/~sm/Publications/
Can you elaborate a bit more on this point? But I'm already sensing it's not an easy things to do with OpenAL.
For the capturing, your system of timestamps should have worked just fine, however I don't think you can accurately predict when the buffers sent by OpenAL will reach the sound card. If I remember correctly, that was also part of a big rant from Jonathan Blow when discussing a port of Braid for linux on his blog.
That isn't a big deal as visuals will react immediately (that is within the same frame, which should be more than enough for human perception, unless you're running at 10 FPS
I'm glad you found a working solution with PortAudio. Too bad orx didn't fit your requirements, maybe with a future version?
However I'm always willing to improve orx use while trying to keep things as simple as possible for most of the "usual" needs. That being said, writing a PortAudio based plugin and/or extending features through the use of events, which are less intruding than direct API changes, is something that could totally happen and I'd be happy to work in this direction.
iarwain wrote: So in portaudio it works like this: You first register a callback that will be called each time the audio hardware needs new data. the buffers will be created by portaudio. the callback will be called from some fancy high priority/low level audio thread. if I understood it correctly it will be triggered/called from some audio hardware interrupt. the result is that you may not allocate memory and do any disk IO. the upside is that it will even be called if the game itself lags/halts etc.
The important thing is that there is only one callback for the input and the output. this means both use the same clock for the timestamps. furthermore there will be as much samples available from as an input as there are for the output, e.g. if you said you will always want 4096 samples then for each time the callback is called you have to fill the output buffer with 4096 samples and you can fetch 4096 samples from the input buffer. hehe, yeah that is actually the problem, it is too fast!!
for example in my game I have a background sound. now let's say I would like to have some audio effects as soons as a specific part of the background sound is currently played. because of all the buffering the background music will not be played back as soon as the output buffer is filled but probably several hundret milli seconds later. so I have to delay the visuals by exactly the time. otherwise you would first see the specific effect and then after XY milli seconds you would hear the sound.
but in order to do that you need to rely on the same clock andsome information about the output latency.
similar stuff is true for the input.
I think it might be the same hardware-interrupt way of working for non-software versions of OpenAL.
Thanks for the details! That's very helpful. Currently sound input/output is on the same clock in orx, but not on the same ticks. It's easy to change so I'll do it tonight and make sure that if a recording callback is called it'll always be synchronized with any input buffering.
Ok, now I understand better your issue.
If you'd like to give it a try, I'd be happy to make such changes. Even if it's no use anymore for you, it'd be so as to see if orx could achieve similar results for projects that are very demanding on sound synchronization.
however I would be willing to test the implementation inside the orx engine and compare the performance.
I already made the one so that recording and playback streaming are synchronized.