full-duplex - is it possible with rme32?

full-duplex - is it possible with rme32?

[Martin Langer]

Hi,

the RME Digi 32 in half-duplex is working so far, but I don't see a solution
for a full-duplex support, because this card is working with one buffer for
recording and playing.

A driver should write the playing data and read the recording data in one
cycle at the same address. There is no way to separate play/rec. It's just
working in a synchronized way: first get the rec-data and then overwrite it
with play-data, cycle for cycle,...

Can I manage it with alsa? I don't think so, but I'm new here and not so
familiar with alsa.

Any Ideas? Is there another module, which works similar?
Or: Sorry, that's not full-alsa-duplex!


thanks,
martin


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: full-duplex - is it possible with rme32?

[Takashi Iwai]

At Thu, 2 May 2002 23:44:00 +0200,
Martin Langer wrote:
> 
> the RME Digi 32 in half-duplex is working so far, but I don't see a solution
> for a full-duplex support, because this card is working with one buffer for
> recording and playing.
> 
> A driver should write the playing data and read the recording data in one
> cycle at the same address. There is no way to separate play/rec. It's just
> working in a synchronized way: first get the rec-data and then overwrite it
> with play-data, cycle for cycle,...

does the capture sample always overwrite the sample to be played?
i.e. if the hardware sequence is
	capture -> playback
on the same pointer, then i have no idea how to do full duplex at
all.  but if the hardware does
	playback -> capture
then there must be no problem.


Takashi

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: full-duplex - is it possible with rme32?

[Martin Langer]

On Fri, May 03, 2002 at 02:55:23PM +0200, Takashi Iwai wrote:
> At Thu, 2 May 2002 23:44:00 +0200, Martin Langer wrote:
> > 
> > the RME Digi 32 in half-duplex is working so far, but I don't see a solution
> > for a full-duplex support, because this card is working with one buffer for
> > recording and playing.
> > 
> > A driver should write the playing data and read the recording data in one
> > cycle at the same address. There is no way to separate play/rec. It's just
> > working in a synchronized way: first get the rec-data and then overwrite it
> > with play-data, cycle for cycle,...
> 
> does the capture sample always overwrite the sample to be played?
> i.e. if the hardware sequence is
> 	capture -> playback
> on the same pointer, then i have no idea how to do full duplex at
> all.  but if the hardware does
> 	playback -> capture
> then there must be no problem.
> 

I'm not sure about my card. In the description I see both cases and I
don't know the right one (or the mistake) up to now.

I just can say "playback -> capture" looks more plausible for me at the
moment, so I hope having this case.

Definitely I can say this: Using the card ends in
- playing plays the play-data
- capturing captures the play-data in full-duplex-mode
- capturing captures the capture-data in half-duplex-mode

or with some different code (this code produces input/output errors):
- playing silence in full-duplex-mode
- capturing the capture-data in full-duplex-mode

Does another module exist, which works in that "playback -> capture" mode? 


martin

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: full-duplex - is it possible with rme32?

[Martin Langer]

On Mon, May 06, 2002 at 11:48:33PM +0200, Martin Langer wrote:
> On Fri, May 03, 2002 at 02:55:23PM +0200, Takashi Iwai wrote:
> > At Thu, 2 May 2002 23:44:00 +0200, Martin Langer wrote:
> > > 
> > > the RME Digi 32 in half-duplex is working so far, but I don't see a solution
> > > for a full-duplex support, because this card is working with one buffer for
> > > recording and playing.
> > > 
> > > A driver should write the playing data and read the recording data in one
> > > cycle at the same address. There is no way to separate play/rec. It's just
> > > working in a synchronized way: first get the rec-data and then overwrite it
> > > with play-data, cycle for cycle,...
> > 
> > does the capture sample always overwrite the sample to be played?
> > i.e. if the hardware sequence is
> > 	capture -> playback
> > on the same pointer, then i have no idea how to do full duplex at
> > all.  but if the hardware does
> > 	playback -> capture
> > then there must be no problem.
> > 
> 
> I'm not sure about my card. In the description I see both cases and I
> don't know the right one (or the mistake) up to now.
> 

I asked RME about the real behaviour and the answer was something like this:
The sample for playing is the first one in the buffer. Capturing at the same
time will overwrite this sample...

So we have the hardware sequence: capture -> playback
and this is like "good-bye full duplex!" for the rme32.


martin


----------------------------------------------------------------------------
                   Bringing you mounds of caffeinated joy
                      >>>     http://thinkgeek.com/sf    <<<

Re: full-duplex - is it possible with rme32?

[vanDongen/Gilcher]

I wonder how the mac driver does it, because I have full duplex working on 
my mac with an rme32/8.
It must be possible. 


> 
> I asked RME about the real behaviour and the answer was something like 
> this:
> The sample for playing is the first one in the buffer. Capturing at the 
> same
> time will overwrite this sample...
> 
> So we have the hardware sequence: capture -> playback
> and this is like "good-bye full duplex!" for the rme32.
>

I don't think this is  a conclusion you make from that info. 

Gerard


----------------------------------------------------------------------------
                   Bringing you mounds of caffeinated joy
                   >>>     http://thinkgeek.com/sf    <<<