On 4/20/2013 5:07 PM, adrien courdavault wrote:

Is there an existing work started inside boost in this subject ? I would be happy to help on this issue.

I have to study ASIO to see the design style, but I have already used most of existing audio device API and librairies that provides portable APIs for this.

Not that I know of, seems like it would be a good addition.

I looked at the documentation on the web site and at ASIO. However I will probably have to ask a lot of questions about ASIO phylosophy. It clearly looks like it would be better if possible to extend ASIO to manage audio devices than creating a new lib. But this suppose that I progress on ASIO understanding. I think I will have to make a different post on this subject in the future. PS, if anyone has feedbacks on this reflection you are welcome. On 21 April 2013 10:29, adrien courdavault wrote:

I will try to see in Trac if anything is related to this and how I could perhaps make a basic. Any help on both the procedure of writing a proposal or the audio_device problem is really welcome to give me directions or advices. I actually don't know what is the procedure for that kind of thing usually.

On 21 April 2013 04:11, Michael Marcin wrote:

...

On 4/20/2013 5:07 PM, adrien courdavault wrote:

...

Is there an existing work started inside boost in this subject ? I would be happy to help on this issue.

I have to study ASIO to see the design style, but I have already used most of existing audio device API and librairies that provides portable APIs for this.

Not that I know of, seems like it would be a good addition.

______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boosthttp://lists.boost.org/mailman/listinfo.cgi/boost

On Sun, Apr 21, 2013 at 11:16:24PM +0200, adrien courdavault wrote:

I looked at the documentation on the web site and at ASIO.

However I will probably have to ask a lot of questions about ASIO phylosophy. It clearly looks like it would be better if possible to extend ASIO to manage audio devices than creating a new lib. But this suppose that I progress on ASIO understanding. I think I will have to make a different post on this subject in the future.

PS, if anyone has feedbacks on this reflection you are welcome.

When talking about audio, please try to be Very Careful to say 'Asio' or 'Boost.Asio' when talking about 'Boost.Asio', as 'ASIO' is an audio output technology in the domain, something very different. This thread made no sense to anyone interpreting 'ASIO' as 'ASIO' and not 'Boost.Asio'. Proper naming matters, folks. -- Lars Viklund | zao@acc.umu.se

Hi @Boris S: Thank you a lot for the presentation. @Lars V: Yes I totally agree with you, I remember that when I discovered Bosst some years ago I event thought it was for Steinberg ASIO, I think I will try to specify Steinberg or Boost.ASIO all the time to be clear. @Brendon C: Yes this is my first concern. In fact I have more experience in audio threads, than in Boost.ASIO. I suppose it should be possible, basically I think this is a compmlete kind of new Boost.ASIO service (not networking, neither, serial or anything else). Also the purpose of the lib would be to provide a socket equivalent that can request the audio service to open an audio device, and then connect on it an audio callback which will be called in the audio thread. I don't expect any of the service, or socket to be called in the audio thread. i suppose that the user will open the device from a user thread. and connect his audio callback. The only thig that I may implement in the audio thread is the buffer desinterleaving, or the format conversion, but this will be specific function not related to the rest of Boost.ASIO and should not be a problem I'm also wondering how to selec the driver family. On MAC there is Coreaudio, which handles all the devices On Win, there is wasapi, directx, Steinberg ASIO familys of driver which can all map any device (as long as the manufacturer provided a compatible driver). On Linux, there is Alsa and PulseAudio I think. I guess this should be choosen when creating the socket. Thank you for your feedbacks On 22 April 2013 03:37, Brendon Costa wrote:

One thing I think you should certainly check into with using boost::asio, (I don't know a lot about boost::asio except its usage), is the realtime nature of the audio threads and whether that can be guaranteed with asio.

Quite often the audio callbacks fired from the various audio subsystems are not "user" threads and have certain restrictions on their usage such as not permitting memory allocations, usage of locks etc within the threads without possible discontinuities in the audio stream. Basically the actual code in these callbacks should be quite limited and maybe asio is not suitable for dispatching these.

For example see: http://portaudio.com/docs/v19-doxydocs/api_overview.html (The Callback I/O Method)

You can relax these restrictions by introducing extra buffering (and latency), but for many applications increasing latency is not preferable or even acceptable.

What is the scope of this idea? Are you planning just to wrap existing cross platform API's previously mentioned? What sorts of features would you provide?

On Monday, 22 April 2013, adrien courdavault wrote:

...

I looked at the documentation on the web site and at ASIO.

However I will probably have to ask a lot of questions about ASIO phylosophy. It clearly looks like it would be better if possible to extend ASIO to manage audio devices than creating a new lib. But this suppose that I progress on ASIO understanding. I think I will have to make a different post on this subject in the future.

PS, if anyone has feedbacks on this reflection you are welcome.

On 21 April 2013 10:29, adrien courdavault javascript:;

...

wrote:

...

I will try to see in Trac if anything is related to this and how I could perhaps make a basic. Any help on both the procedure of writing a proposal or the audio_device problem is really welcome to give me directions or advices. I actually don't know what is the procedure for that kind of thing usually.

On 21 April 2013 04:11, Michael Marcin javascript:;> wrote:

...

On 4/20/2013 5:07 PM, adrien courdavault wrote:

...

Is there an existing work started inside boost in this subject ? I would be happy to help on this issue.

I have to study ASIO to see the design style, but I have already used most of existing audio device API and librairies that provides portable APIs for this.

Not that I know of, seems like it would be a good addition.

______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost< http://lists.boost.org/mailman/listinfo.cgi/boost>

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thank you in advance, Yes I would be really pleased by any help on this. First I have to make some progress on the understanding of Boost ASIO and see if this is the best direction. Anyway again any help is welcome. Best On 22 April 2013 10:51, Philip Bennefall wrote:

----- Original Message ----- From: "adrien courdavault" To: "boost" Sent: Monday, April 22, 2013 10:27 AM Subject: Re: [boost] media > audio project (gsoc or future boost)

Hi

@Boris S: Thank you a lot for the presentation.

@Lars V: Yes I totally agree with you, I remember that when I discovered Bosst some years ago I event thought it was for Steinberg ASIO, I think I will try to specify Steinberg or Boost.ASIO all the time to be clear.

@Brendon C: Yes this is my first concern. In fact I have more experience in audio threads, than in Boost.ASIO. I suppose it should be possible, basically I think this is a compmlete kind of new Boost.ASIO service (not networking, neither, serial or anything else). Also the purpose of the lib would be to provide a socket equivalent that can request the audio service to open an audio device, and then connect on it an audio callback which will be called in the audio thread. I don't expect any of the service, or socket to be called in the audio thread. i suppose that the user will open the device from a user thread. and connect his audio callback. The only thig that I may implement in the audio thread is the buffer desinterleaving, or the format conversion, but this will be specific function not related to the rest of Boost.ASIO and should not be a problem

I'm also wondering how to selec the driver family.

On MAC there is Coreaudio, which handles all the devices On Win, there is wasapi, directx, Steinberg ASIO familys of driver which can all map any device (as long as the manufacturer provided a compatible driver). On Linux, there is Alsa and PulseAudio I think.

I guess this should be choosen when creating the socket.

Thank you for your feedbacks

Hi Adrien,

I just wanted to chime in and say that I think this is a fabulous idea. I have wanted something like this to be available in Boost for a long time. I would be more than willing to help contribute code if I can, as I have done some work with audio I/O under Windows. I can also do testing, should you find it useful.

Kind regards,

Philip Bennefall

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost