full/half duplex support

full/half duplex support

[Luuk van Dijk]

LS. 

I am currently writing a driver for the ADI 1836 on the (ongoing) 
blackfin/uclinux port (blackfin.uclinux.org) and I have some questions (that 
I'll post in separate mails, so that they may be separate threads) 

The particular hardware configuration I am programming for is full-duplex in 
principle, i.e. it should be no problem to send and receive pcm bitstreams 
simultaneously, except that it requires that both dma channels are started 
simultaneously.  Currently, I configure an unused substream with a dummy dma 
buffer, but the alsa mid layer seems to handle this badly: it appears to 
re-triggers the last-started substream when it finds out that the dma is at 
an other address than it expects. 

my question is: is there a way around this, i.e. can I tell the mid layer to 
resync itself with the dma instead of the other way around? 

thanks
   Luuk van Dijk


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: full/half duplex support

[Takashi Iwai]

At Mon, 15 Nov 2004 17:03:21 +0100,
Luuk van Dijk wrote:
> 
> LS. 
> 
> I am currently writing a driver for the ADI 1836 on the (ongoing) 
> blackfin/uclinux port (blackfin.uclinux.org) and I have some questions (that 
> I'll post in separate mails, so that they may be separate threads) 
> 
> The particular hardware configuration I am programming for is full-duplex in 
> principle, i.e. it should be no problem to send and receive pcm bitstreams 
> simultaneously, except that it requires that both dma channels are started 
> simultaneously.  Currently, I configure an unused substream with a dummy dma 
> buffer, but the alsa mid layer seems to handle this badly: it appears to 
> re-triggers the last-started substream when it finds out that the dma is at 
> an other address than it expects. 

Sorry, the situation is not clear for me.
Do you mean substream as the ALSA term?

So, you have two or more substreams assigned to a single PCM device,
and the DMAs are free-running when the substreams are unused?


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: full/half duplex support

[Luuk van Dijk]

On Thu, 2004-11-18 at 14:17, Takashi Iwai wrote:
> At Mon, 15 Nov 2004 17:03:21 +0100,
> Luuk van Dijk wrote:
> > 
> Sorry, the situation is not clear for me.
> Do you mean substream as the ALSA term?

yes. 

> So, you have two or more substreams assigned to a single PCM device,
> and the DMAs are free-running when the substreams are unused?

yes, one capture and one playback substream, both of 2,4,6 or 8
channels.  when one of the two is not used the dma is free running and I
disable its irq's.  the problem is: they have to be started and stopped
simultaneously and cannot be paused.

i think the problem would be solved if the mid layer would just accept
the current pointer, and adjust its communication to userspace based on
that instead of trying to force the dma to sync with its idea of what it
should be.  but I could be talking out of my *ss here, since I'm
relatively new to alsa.  (this is my first alsa driver :-)


thanks
	Luuk



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: full/half duplex support

[Takashi Iwai]

At 18 Nov 2004 19:06:45 +0100,
Luuk van Dijk wrote:
> 
> On Thu, 2004-11-18 at 14:17, Takashi Iwai wrote:
> > At Mon, 15 Nov 2004 17:03:21 +0100,
> > Luuk van Dijk wrote:
> > > 
> > Sorry, the situation is not clear for me.
> > Do you mean substream as the ALSA term?
> 
> yes. 
> 
> > So, you have two or more substreams assigned to a single PCM device,
> > and the DMAs are free-running when the substreams are unused?
> 
> yes, one capture and one playback substream, both of 2,4,6 or 8
> channels.  when one of the two is not used the dma is free running and I
> disable its irq's.  the problem is: they have to be started and stopped
> simultaneously and cannot be paused.
> 
> i think the problem would be solved if the mid layer would just accept
> the current pointer, and adjust its communication to userspace based on
> that instead of trying to force the dma to sync with its idea of what it
> should be.  but I could be talking out of my *ss here, since I'm
> relatively new to alsa.  (this is my first alsa driver :-)

Hmm, I don't understand your proposal here.

AFAIUC, the problem is that the trigger callback is called twice, for
playback and capture, on the full-duplex mode.  Basically ALSA assumes
that the playback and the capture streams are accessible
independently, so no such restriction is implemented (yet).

If my understanding is right -- I'd recommend to add a code in the
trigger callback just to check whether another stream has been already
triggered, then simply ignore the second trigger call.
Also, it'd be better to provide the sync start option so that the
full-duplex app triggers only once.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: full/half duplex support

[Luuk van Dijk]

On Fri, 2004-11-19 at 13:13, Takashi Iwai wrote:

> Hmm, I don't understand your proposal here.
> 
> AFAIUC, the problem is that the trigger callback is called twice, for
> playback and capture, on the full-duplex mode.  Basically ALSA assumes
> that the playback and the capture streams are accessible
> independently, so no such restriction is implemented (yet).

no it looks like the callback is called multiple times for the second
stream that is started.   so: hwparams() and prepare() and trigger() for
the first, say the capture substream works fine.  then I start the
playback substream.  my prepare() knows to reconfig the dma when either
channel is running, so that goes well too, and the trigger() knows that
if either substream is running it doesn't need to start the dma i/o, but
then the mid-layer queries the current dma pointer for the capture
stream with the pointer() callback, and I think it doesn't like the
answer (my interpretation), because I see that it calls trigger() again
and again.

> If my understanding is right -- I'd recommend to add a code in the
> trigger callback just to check whether another stream has been already
> triggered, then simply ignore the second trigger call.

I already did that. but it doesn't solve the problem, which I described
above.

> Also, it'd be better to provide the sync start option so that the
> full-duplex app triggers only once.

that may be a good idea, thanks so far. I'll look into it & let you
know.

R,
	L.



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: full/half duplex support

[Takashi Iwai]

At 19 Nov 2004 21:29:31 +0100,
Luuk van Dijk wrote:
> 
> On Fri, 2004-11-19 at 13:13, Takashi Iwai wrote:
> 
> > Hmm, I don't understand your proposal here.
> > 
> > AFAIUC, the problem is that the trigger callback is called twice, for
> > playback and capture, on the full-duplex mode.  Basically ALSA assumes
> > that the playback and the capture streams are accessible
> > independently, so no such restriction is implemented (yet).
> 
> no it looks like the callback is called multiple times for the second
> stream that is started.   so: hwparams() and prepare() and trigger() for
> the first, say the capture substream works fine.  then I start the
> playback substream.  my prepare() knows to reconfig the dma when either
> channel is running, so that goes well too, and the trigger() knows that
> if either substream is running it doesn't need to start the dma i/o, but
> then the mid-layer queries the current dma pointer for the capture
> stream with the pointer() callback, and I think it doesn't like the
> answer (my interpretation), because I see that it calls trigger() again
> and again.

Then something wrong in the callback routines.  Perhaps the pointer
callback doesn't return the proper expected position, and the core or
the application tries to stop/restart the stream.

The trigger(START) callback is called only in the three places.
One is the SND_PCM_START ioctl, one in the write, and one in the
read to start the stream.  In any cases, the current status is checked
before the callback is called.  So, the fact that the trigger callback
is called many times implies that the PCM state remains PREPARED even
after the first call.


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/