Re: [Mustux-devel] Regarding ALSA implementation

[Remon Sijrier]

Thanks,

It makes much clear about the current implementation. 

Then I will try to modify it a bit to see if it helps to solve the problem 
Reinhard has. It shouldn't "hang" with plughw, it still looks like it is 
waiting to be "unlocked" in the same manner as it is when another app. has 
the soundcard.
If it doesn't work, then I'm really sorry Reinhard ;-(
But as you see, all the good stuff is under the way. (Do you say it like that 
in English?)

Oh, and try to upgrade to the latest alsa version, I've read somewhere that 
Mandrake ships with quite an old version of alsa!

Thanks,

Remon


On Thursday 13 November 2003 21:56, Luciano Giordana wrote:
> > 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