Re: [boost] media > audio project (gsoc or future boost)

Subject: Re: [boost] media > audio project (gsoc or future boost)
From: adrien courdavault (adrien.courdavault_at_[hidden])
Date: 2013-04-22 04:27:04

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 <brendon.j.costa_at_[hidden]> 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 <adrien.courdavault_at_[hidden]<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 <mike.marcin_at_[hidden]<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