All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Alan Horstmann <gineera@aspect135.co.uk>
Cc: ALSA devel <alsa-devel@alsa-project.org>
Subject: Re: Alsa-OSS Duplex bug (revisited)
Date: Mon, 04 Jun 2007 10:50:59 +0200	[thread overview]
Message-ID: <s5htztoayrw.wl%tiwai@suse.de> (raw)
In-Reply-To: <200706032055.27495.gineera@aspect135.co.uk>

At Sun, 3 Jun 2007 20:55:27 +0100,
Alan Horstmann wrote:
> 
> On Friday 01 June 2007 10:56, you wrote:
> > At Thu, 31 May 2007 22:00:25 +0100,
> >
> > Alan Horstmann wrote:
> > > On Wednesday 30 May 2007 07:47, you wrote:
> > > > Alan Horstmann wrote:
> 
> << Edited snippets >>
> 
> > > > fd_playback = open("/dev/dsp", O_WRONLY);
> > > > fd_capture = open("/dev/dsp", O_RDONLY);
> > > >
> > > > > > - change portaudio to open each direction separately, O_RDONLY and
> > > > > >   O_WRONLY at first, then use O_RDWR as fallback
> > > >
> > > > This would be the preferred way.  After all, this is the only way that
> > > > is possible with the existing OSS API when you want to use different
> > > > sample formats, and it is recommended in all cases (see
> > > > <http://manuals.opensound.com/developer/full_duplex.html>).
> > >
> > > My reading of the 4Front info is different.  I read that they recommend
> > > best opening SEPARATE devices, one O_RDONLY and the other O_WRONLY, in
> > > their scheme called 'twodevice'.  It also states in fulldup.c:-
> > >
> > > "... The one device full duplex scheme requires that the device file is
> > > opened with O_RDWR."
> > >
> 
> > Well, I'd say that the current ALSA-OSS implementation _is_ compatible
> > to OSS API.  What they do is also a pure hack, as you know, just a
> > workaround because the API doesn't provide the functionality
> > properly for full-duplex with multi-channels.  The solution might be
> > different, but it's not the question about "compatibility".
> >
> >
> > Following this thread, I come to believe that the problem with
> > audacity is actually the application problem.  It tries to open a
> > full-duplex device with different number of channels for both
> > directions.  It cannot work because it's not defined in API.  OTOH, if
> > the number of channels are same for both directions, it should work
> > with O_RDWR.
> >
> 
> Thanks for sticking with it so far -hopefully we are moving towards a 
> conclusion so that the result is a definitive recommendation for how to solve 
> the problem of the OSS API limitation.
> 
> So that there is no misunderstanding, are you willing to confirm that, as far 
> as Alsa-OSS goes, opening both
> 	input_handle = open("/dev/dsp", O_RDONLY)
> and
> 	output_handle = open("/dev/dsp", O_WRONLY)
> at the same time is a reliable way to open the device bi-directional, enabling 
> different sample formats and/or numbers of channels to be set?  (Actually, I 
> am curious whether different sample rates would also work?)

Yes, although I didn't confirm it.  If it doesn't work, we should
really fix it.  The dirrerent sample rates should work, too, because
they are different streams.

> Provided this is so, the recommendation then for duplex as I understand it 
> is:-
> 	a) where the format and no.channels is the same in each direction, 
> 	    use 
> 		input_handle = output_handle = open("device", O_RDWR)
> 
> 	b) where the 2 directions have different format or no.channels use
> 		input_handle = open("device", O_RDONLY)
> 		output_handle = open("device", O_WRONLY)
> 
> since a) may improve compatibility with other OSS's but b) is necessary due to 
> the limitations of the OSS API, whether or not it works with other OSS's.

Exactly.  But, remember that the solution for this kind of problems
must be practical - if the theory above isn't true for the practice,
it's of course useless :)


Takashi

  parent reply	other threads:[~2007-06-04  8:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-27 22:23 Alsa-OSS Duplex bug (revisited) Alan Horstmann
2007-05-29 16:55 ` Takashi Iwai
2007-05-29 22:16   ` Alan Horstmann
2007-05-30  6:47     ` Clemens Ladisch
2007-05-30 17:05       ` Takashi Iwai
2007-05-30 22:12         ` Alan Horstmann
2007-05-31 21:00       ` Alan Horstmann
2007-06-01  9:56         ` Takashi Iwai
2007-06-03 19:55           ` Alan Horstmann
2007-06-04  8:45             ` Clemens Ladisch
2007-06-04 11:51               ` Alan Horstmann
2007-06-04  8:50             ` Takashi Iwai [this message]
2007-06-04 11:53               ` Alan Horstmann
2007-06-04 12:21                 ` Takashi Iwai
2007-06-04 20:42                   ` Alan Horstmann
2007-06-04 21:14                     ` Takashi Iwai

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=s5htztoayrw.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=gineera@aspect135.co.uk \
    /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.