Re: [Mustux-devel] Regarding ALSA implementation

[Luciano Giordana]

> 1. Why isn't the alsa implementation done with a callback mechanism?

Threaded engines are much more robust than callback driven engines. 
It guaranties that a process is handling the data in/out stream while callback
engines cannot guarantee since it varie on local machine system clock 
resolution.

Sometimes you get glitches with callback machanims. We had a callback driven 
engine in past protux releases,
we moved to threaded engine, after a lot of hard work... (check past ChangeLogs)


> 2. Trying to solve the bug for Reinhard in MADM (=MAB) I realized that
> there is much work to be done for the alsa implementation. One of the
> things I do not understand is:
> MAB is designed full duplex, but when taking a closer look, its just doing
> one job at a time.

There is no "full duplex" concept in alsa. Check Alsa docs. You have to handle 
in stuff and out stuff completely separatedly.
I confess I prefer this way, it is more transparent.


> This is what happens in all methods which are alsa related (transferring
> data, opening busses, etc... ):
>
> if (stream==MustuxAudioDeviceMapper::CAPTURE)
>       {
>       do all things related to capture,
>       when finished, end this method,
>       so only the capture is handled;
>       }
> else
>       {
>       do all things related to playback,
>       when finished, end this method,
>       so only the playback is handled;
>       }
>

yes, because a bus is either a playback bus or a capture bus.

> My suggestion is, make "playback" and "capture" separate things, and have
> all alsa parameters for both "playback" and "capture"

It was like this in the past, we had many trouble. MADM is one of the things in 
libmustux that is almost
freezed exactly because after a lot of mistakes, we found a good architeture to 
wrap ALSA stuff.

> Mixer then has only 1 thread, which only calls Bus->transfer(blabla) an all
> duplex stuff will be handled within Bus::transfer (like in Bus::open)
> _at_the_same_time_ !
> Synchronizing playback/capture streams is also much easier from within 1
> thread?

if you have concident fps's you dont have to worry about 2 threads, because the 
same amout of audio will be coming from both in and out buses.

> Then there will be the multiple bit depth support, and thats something out
> of my sight. So I wanted to know from you what you think about all this, it
> requires some huge changes, but IMHO we will end up with a much stabler
> MustuxAudioBus related to alsa stuff. Also mixer will have only one thread
> instead of two, which makes life easier. (synchronizing two threads, or
> actually the dataflow in these threads, how to do that?)

I honestly dont want to change the way that MADM is wraping ALSA stuff. It 
required a LOT of work in 2003 to reach the point it is now,
I revised it many times, and I believe it is pretty fine. 

If there are bugs, we will found them. But the architeture is quite smooth I 
guess.

Also the multiple bit support is more a application issue than a MADM issue. 
And it is on the way.

Thanks

-- 
Best Regards
--
Luciano Giordana
Project Mustux - Musician Tools for GNU/Linux
http://www.freesoftware.fsf.org/mustux