On Wed, 7 Jan 2004, Takashi Iwai wrote:
> there are two parts to be modified, snd_pcm_open_noupdate() and
> snd_pcm_slave_conf(). they are the parts which look up "pcm"
> directive in the configuration.
> the former is easy. but the latter function doesn't have stream
> argument, so it cannot ch
At Wed, 07 Jan 2004 17:58:10 +0100,
Abramo Bagnara wrote:
>
> Takashi Iwai wrote:
> >>>
> >>> pcm.foo {
> >>> type plug
> >>> slave {
> >>> pcm bar
> >>> }
> >>> }
> >>> pcmp.bar bar_playback
> >>> pcmc.bar bar_capture
> >>>
> >>>i think it's
Takashi Iwai wrote:
pcm.foo {
type plug
slave {
pcm bar
}
}
pcmp.bar bar_playback
pcmc.bar bar_capture
i think it's a big restriction.
As a matter of personal preference I very much prefer this latte
At Wed, 07 Jan 2004 16:47:53 +0100,
Abramo Bagnara wrote:
>
> Takashi Iwai wrote:
> >
> >
> > if i understand the code correctly, for defining a pcmp or pcmc as a
> > slave pcm, such as,
> >
> > pcm.foo {
> > type plug
> > slave {
> > pcmp bar_pla
Takashi Iwai wrote:
if i understand the code correctly, for defining a pcmp or pcmc as a
slave pcm, such as,
pcm.foo {
type plug
slave {
pcmp bar_playback
pcmc bar_capture
}
}
snd_pcm_s
At Wed, 07 Jan 2004 16:15:40 +0100,
Abramo Bagnara wrote:
>
> Takashi Iwai wrote:
> > At Wed, 07 Jan 2004 15:39:14 +0100,
> > Abramo Bagnara wrote:
> >
> >>
> >>I don't see your point, can you show me an example of what you mean?
> >>
> >>AFAICS the only code that need to be changed is the PCM de
Takashi Iwai wrote:
At Wed, 07 Jan 2004 15:39:14 +0100,
Abramo Bagnara wrote:
I don't see your point, can you show me an example of what you mean?
AFAICS the only code that need to be changed is the PCM definition lookup.
there are two parts to be modified, snd_pcm_open_noupdate() and
snd_pcm_sl
At Wed, 07 Jan 2004 15:39:14 +0100,
Abramo Bagnara wrote:
>
> Takashi Iwai wrote:
> > At Wed, 07 Jan 2004 13:45:05 +0100,
> > Abramo Bagnara wrote:
> >
> >>Takashi Iwai wrote:
> >>
> >>
> >>>as written in my previous mail, it was a quick hack. and there is a
> >>>better approach.
> >>
> >>I'd pr
Takashi Iwai wrote:
At Wed, 07 Jan 2004 13:45:05 +0100,
Abramo Bagnara wrote:
Takashi Iwai wrote:
as written in my previous mail, it was a quick hack. and there is a
better approach.
I'd prefer the following approach:
pcmp.duplex {
type dmix
...
}
pcmc.duplex {
type dsno
At Wed, 7 Jan 2004 14:06:22 +0100,
Florian Schmidt wrote:
>
> On Wed, 7 Jan 2004 13:05:30 +0100
> Florian Schmidt <[EMAIL PROTECTED]> wrote:
>
> > I think of this plugin as making a full duplex pcm out of two half
> > duplex pcm. So why not call the plugin "duplexer"?
"duplex" was my first idea,
At Wed, 07 Jan 2004 13:45:05 +0100,
Abramo Bagnara wrote:
>
> Takashi Iwai wrote:
>
> > as written in my previous mail, it was a quick hack. and there is a
> > better approach.
>
> I'd prefer the following approach:
>
> pcmp.duplex {
> type dmix
> ...
> }
>
> pcmc.duplex {
>
On Wed, 7 Jan 2004 13:05:30 +0100
Florian Schmidt <[EMAIL PROTECTED]> wrote:
> I think of this plugin as making a full duplex pcm out of two half
> duplex pcm. So why not call the plugin "duplexer"?
Btw: This plugin reminds me somewhat of the "multi" plugin since it,
too, combines several pcm's
Takashi Iwai wrote:
as written in my previous mail, it was a quick hack. and there is a
better approach.
I'd prefer the following approach:
pcmp.duplex {
type dmix
...
}
pcmc.duplex {
type dsnoop
...
}
with the following policy:
- if capture is specified pcmc and
On Wed, 07 Jan 2004 12:01:02 +0100
Takashi Iwai <[EMAIL PROTECTED]> wrote:
> as written in my previous mail, it was a quick hack. and there is a
> better approach.
>
> the attached patch will add a new plugin, asym, which defines
> different slave pcms for playback and capture streams.
> for exa
At Tue, 6 Jan 2004 22:38:28 +0100,
Florian Schmidt wrote:
>
> On Tue, 6 Jan 2004 11:05:52 -0600 (CST)
> David Lloyd <[EMAIL PROTECTED]> wrote:
>
> > This patch works great - I'm now able to use TeamSpeak (which opens
> > capture and playback through oss) at the same time as xmms.
> >
>
> Cool.
On Tue, 6 Jan 2004 11:05:52 -0600 (CST)
David Lloyd <[EMAIL PROTECTED]> wrote:
> This patch works great - I'm now able to use TeamSpeak (which opens
> capture and playback through oss) at the same time as xmms.
>
Cool.. this sounds good. Great news! Thanks, Takashi.. Is there a chance
of this g
On Mon, 5 Jan 2004, Takashi Iwai wrote:
> anyway, it's possible if you use aoss wrapper and specify dmix/dsnoop as
> the device. you're right for the kernel emulation. no way. but still
> we need a fix for aoss wrapper. the only necessary change is to allow
> aoss open different pcm per playbac
>> >I have application A that needs to open payback and capture streams
>> >because it's a two-way communications program. Application B is a game
>> >that uses playback only. I want to use these both at the same time.
>>
>> but i don't think you can do this with OSS. why should ALSA's OSS
>>
At Mon, 05 Jan 2004 12:41:12 -0500,
Paul Davis wrote:
>
> >I have application A that needs to open payback and capture streams
> >because it's a two-way communications program. Application B is a game
> >that uses playback only. I want to use these both at the same time.
>
> but i don't think
On Mon, 5 Jan 2004, Paul Davis wrote:
> >I have application A that needs to open payback and capture streams
> >because it's a two-way communications program. Application B is a game
> >that uses playback only. I want to use these both at the same time.
>
> but i don't think you can do this w
>I have application A that needs to open payback and capture streams
>because it's a two-way communications program. Application B is a game
>that uses playback only. I want to use these both at the same time.
but i don't think you can do this with OSS. why should ALSA's OSS
emulation make it
On Mon, 5 Jan 2004, Jaroslav Kysela wrote:
> What's your problems? ALSA applications should offer you to set the
> playback and capture devices independently. If you bother with the OSS
> emulation, simply change the code in oss_dsp_open() -
> alsa-oss/alsa-oss.c. Perhaps, we can do it for you.
T
On Mon, 5 Jan 2004 17:28:33 +0100 (CET)
Jaroslav Kysela <[EMAIL PROTECTED]> wrote:
> > That is exactly the problem! DMIX is for playback. DSNOOP is for
> > capture. Where is the module that is for both? Why, oh why, did
> > they not simply make ONE MODULE in the first place??
>
> Both are lo
On Mon, 5 Jan 2004, Takashi Iwai wrote:
> At Mon, 5 Jan 2004 10:29:01 -0600 (CST),
> David Lloyd wrote:
> >
> > On Sun, 4 Jan 2004, Paul Davis wrote:
> >
> > > >I'm working on changing DMIX to allow clients to open the capture stream.
> > >
> > > i don't get it. dmix is for playback, not capt
At Mon, 5 Jan 2004 17:28:33 +0100 (CET),
Jaroslav wrote:
>
> > The semantics would be (rather would have been) that if someone tries to
> > open the capture stream through the dmix plugin, it will "pass through" to
> > the slave. This means that while many apps can open playback stream, only
> >
At Mon, 5 Jan 2004 10:29:01 -0600 (CST),
David Lloyd wrote:
>
> On Sun, 4 Jan 2004, Paul Davis wrote:
>
> > >I'm working on changing DMIX to allow clients to open the capture stream.
> >
> > i don't get it. dmix is for playback, not capture. what would be the
> > semantics of this?
>
> That i
On Mon, 5 Jan 2004, David Lloyd wrote:
> On Sun, 4 Jan 2004, Paul Davis wrote:
>
> > >I'm working on changing DMIX to allow clients to open the capture stream.
> >
> > i don't get it. dmix is for playback, not capture. what would be the
> > semantics of this?
>
> That is exactly the problem!
On Sun, 4 Jan 2004, Paul Davis wrote:
> >I'm working on changing DMIX to allow clients to open the capture stream.
>
> i don't get it. dmix is for playback, not capture. what would be the
> semantics of this?
That is exactly the problem! DMIX is for playback. DSNOOP is for
capture. Where i
On Mon, 5 Jan 2004, David Lloyd wrote:
> On Mon, 5 Jan 2004, Patrick Shirkey wrote:
>
> > David Lloyd wrote:
> >
> > Recent discussion of this has made it clear that in the near future
> > Jaroslav and Takashi are planning on implementing better
> > interoperability between dmix and dsnoop.
> >
On Mon, 5 Jan 2004, Patrick Shirkey wrote:
> David Lloyd wrote:
>
> Recent discussion of this has made it clear that in the near future
> Jaroslav and Takashi are planning on implementing better
> interoperability between dmix and dsnoop.
>
> It's not high on the list of priorities because there
David Lloyd wrote:
On Sun, 4 Jan 2004, Florian Schmidt wrote:
On Sun, 04 Jan 2004 00:07:26 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
I'm working on changing DMIX to allow clients to open the capture
stream.
i don't get it. dmix is for playback, not capture. what would be the
semantics of thi
On Sun, 4 Jan 2004 18:02:11 -0600 (CST)
David Lloyd <[EMAIL PROTECTED]> wrote:
> This is exacly my point. The fact that dmix and dsnoop are
> half-duplex is where I have a problem. There seems to be no way to
> allow more than one OSS-compatibility client to share audio in a
> satisfactory way.
On Sun, 4 Jan 2004, Florian Schmidt wrote:
> On Sun, 04 Jan 2004 00:07:26 -0500
> Paul Davis <[EMAIL PROTECTED]> wrote:
>
> > >I'm working on changing DMIX to allow clients to open the capture
> > >stream.
> >
> > i don't get it. dmix is for playback, not capture. what would be the
> > semanti
On Sun, 04 Jan 2004 00:07:26 -0500
Paul Davis <[EMAIL PROTECTED]> wrote:
> >I'm working on changing DMIX to allow clients to open the capture
> >stream.
>
> i don't get it. dmix is for playback, not capture. what would be the
> semantics of this?
Hmm, i don't know the OP's answer to this, but
Paul Davis wrote:
I'm working on changing DMIX to allow clients to open the capture stream.
i don't get it. dmix is for playback, not capture. what would be the
semantics of this?
haven't tried yet, but isn't "dsnoop" the dmix equivalent for capture ?
--
In this house, we obey the laws of ther
>I'm working on changing DMIX to allow clients to open the capture stream.
i don't get it. dmix is for playback, not capture. what would be the
semantics of this?
--p
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expe
I'm working on changing DMIX to allow clients to open the capture stream.
But I've hit a bit of a block with how to proceed. Since it would seem
that a slave snd_pcm_t can only be opened either for capture or playback,
it would seem to follow that one would need a second handle to be able to
ope
37 matches
Mail list logo
