All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Langer <martin-langer@gmx.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: full-duplex - is it possible with rme32?
Date: Mon, 6 May 2002 23:48:33 +0200	[thread overview]
Message-ID: <20020506214833.GA14102@localhost> (raw)
In-Reply-To: <s5hvga5mlvo.wl@alsa2.suse.de>

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

  reply	other threads:[~2002-05-06 21:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-02 21:44 full-duplex - is it possible with rme32? Martin Langer
2002-05-03 12:55 ` Takashi Iwai
2002-05-06 21:48   ` Martin Langer [this message]
2002-06-17 23:05     ` Martin Langer
     [not found] <E17KOUR-0002SW-00@usw-sf-list2.sourceforge.net>
2002-06-19 11:44 ` vanDongen/Gilcher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020506214833.GA14102@localhost \
    --to=martin-langer@gmx.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.