On Wed, 2005-03-30 at 03:48 +0200, Marcin Dalecki wrote:
> On 2005-03-30, at 01:39, Benjamin Herrenschmidt wrote:
> > Look at the pile of junk that are most winmodem driver implementations,
> > nothing I want to see in the kernel ever. Those things should be in
> > userland.
>
> You are joking?
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
> > I think your misunderstanding is that you beliieve user-space can't do
> > RT. It's wrong. See JACK (jackit.sf.net), for example.
>
> I know JACK in and out. It doesn't provide what you claim.
Are you implying that "He don't know
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
> > I think your misunderstanding is that you beliieve user-space can't do
> > RT. It's wrong. See JACK (jackit.sf.net), for example.
>
> I know JACK in and out. It doesn't provide what you claim.
>
This was just an example, to prove
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
> On 2005-03-29, at 12:22, Takashi Iwai wrote:
> >
> > ALSA provides the "driver" feature in user-space because it's more
> > flexible, more efficient and safer than doing in kernel. It's
> > transparent from apps perspective. It really
On 2005-03-30, at 01:39, Benjamin Herrenschmidt wrote:
On Tue, 2005-03-29 at 17:25 -0600, Chris Friesen wrote:
Lee Revell wrote:
This is the exact line of reasoning that led to Winmodems.
My main issue with winmodems is not so much the software offload, but
rather that the vendors don't release
On 2005-03-30, at 00:13, Lee Revell wrote:
On Tue, 2005-03-29 at 11:22 +0200, Marcin Dalecki wrote:
No. You didn't get it. I'm taking the view that mixing sound is simply
a task you would typically love to make a DSP firmware do.
However providing a DSP for sound processing at 44kHZ on the same
On 2005-03-29, at 12:22, Takashi Iwai wrote:
ALSA provides the "driver" feature in user-space because it's more
flexible, more efficient and safer than doing in kernel. It's
transparent from apps perspective. It really doesn't matter whether
it's in kernel or user space.
Yes because it's that
On Tue, 2005-03-29 at 17:25 -0600, Chris Friesen wrote:
> Lee Revell wrote:
>
> > This is the exact line of reasoning that led to Winmodems.
>
> My main issue with winmodems is not so much the software offload, but
> rather that the vendors don't release full specs.
>
> If all winmodem
Lee Revell wrote:
This is the exact line of reasoning that led to Winmodems.
My main issue with winmodems is not so much the software offload, but
rather that the vendors don't release full specs.
If all winmodem manufacturers released full hardware specs, I doubt
people would really complain
On Tue, 2005-03-29 at 11:22 +0200, Marcin Dalecki wrote:
> No. You didn't get it. I'm taking the view that mixing sound is simply
> a task you would typically love to make a DSP firmware do.
> However providing a DSP for sound processing at 44kHZ on the same
> PCB as an 1GHZ CPU is a ridiculous
On Tue, 2005-03-29 at 21:31 +0200, Takashi Iwai wrote:
> At Tue, 29 Mar 2005 14:05:08 -0500,
> Lee Revell wrote:
> >
> > On Tue, 2005-03-29 at 21:04 +1000, Benjamin Herrenschmidt wrote:
> > > Can the driver advertize in some way what it can do ? depending on the
> > > machine we are running on,
On Tue, 2005-03-29 at 21:31 +0200, Takashi Iwai wrote:
> Well I don't remember the discussion thread on alsa-devel about this,
> but it's a good idea that alsa-lib checks the capability of hw-mixing
> and apples dmix only if necessary. (In the case of softvol, it can
> check the existence of hw
At Tue, 29 Mar 2005 14:05:08 -0500,
Lee Revell wrote:
>
> On Tue, 2005-03-29 at 21:04 +1000, Benjamin Herrenschmidt wrote:
> > Can the driver advertize in some way what it can do ? depending on the
> > machine we are running on, it will or will not be able to do HW volume
> > control... You
On Tue, 2005-03-29 at 21:04 +1000, Benjamin Herrenschmidt wrote:
> Can the driver advertize in some way what it can do ? depending on the
> machine we are running on, it will or will not be able to do HW volume
> control... You probably don't want to use softvol in the former case...
>
> dmix by
At Tue, 29 Mar 2005 21:04:50 +1000,
Benjamin Herrenschmidt wrote:
>
>
> > Yes.
> >
> > > dmix has been around for a while but softvol plugin is very new, you
> > > will need ALSA CVS or the upcoming 1.0.9 release.
> >
> > dmix currently doesn't work on PPC well but I'll fix it soon later.
> >
> Yes.
>
> > dmix has been around for a while but softvol plugin is very new, you
> > will need ALSA CVS or the upcoming 1.0.9 release.
>
> dmix currently doesn't work on PPC well but I'll fix it soon later.
> If it's confirmed to work, we can set dmix/softvol plugins for default
> of
At Tue, 29 Mar 2005 11:22:07 +0200,
Marcin Dalecki wrote:
>
>
> On 2005-03-29, at 10:18, Benjamin Herrenschmidt wrote:
> >
> > Well, we are claiming _and_ obviously proposing a solution ;)
>
> I beg to differ.
>
> >> 1. Where do you have true "real-time" under linux? Kernel or user
> >>
At Mon, 28 Mar 2005 22:36:09 -0500,
Lee Revell wrote:
>
> On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
> > It seems that Apple's driver has an in-kernel framework for doing volume
> > control, mixing, and other horrors right in the kernel, in temporary
> > buffers, just before
On 2005-03-29, at 10:18, Benjamin Herrenschmidt wrote:
Well, we are claiming _and_ obviously proposing a solution ;)
I beg to differ.
1. Where do you have true "real-time" under linux? Kernel or user
space?
That's bullshit.
Wait a moment...
you don't need "true" real time for the mixing/volume
> > dmix has been around for a while but softvol plugin is very new, you
> > will need ALSA CVS or the upcoming 1.0.9 release.
>
> Instead of the lame claims on how ugly it is to do hardware mixing in
> kernel space the ALSA fans should ask them self the following questions:
Well, we are
dmix has been around for a while but softvol plugin is very new, you
will need ALSA CVS or the upcoming 1.0.9 release.
Instead of the lame claims on how ugly it is to do hardware mixing in
kernel space the ALSA fans should ask them self the following questions:
Well, we are claiming _and_
On 2005-03-29, at 10:18, Benjamin Herrenschmidt wrote:
Well, we are claiming _and_ obviously proposing a solution ;)
I beg to differ.
1. Where do you have true real-time under linux? Kernel or user
space?
That's bullshit.
Wait a moment...
you don't need true real time for the mixing/volume
At Mon, 28 Mar 2005 22:36:09 -0500,
Lee Revell wrote:
On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
It seems that Apple's driver has an in-kernel framework for doing volume
control, mixing, and other horrors right in the kernel, in temporary
buffers, just before they
At Tue, 29 Mar 2005 11:22:07 +0200,
Marcin Dalecki wrote:
On 2005-03-29, at 10:18, Benjamin Herrenschmidt wrote:
Well, we are claiming _and_ obviously proposing a solution ;)
I beg to differ.
1. Where do you have true real-time under linux? Kernel or user
space?
That's
Yes.
dmix has been around for a while but softvol plugin is very new, you
will need ALSA CVS or the upcoming 1.0.9 release.
dmix currently doesn't work on PPC well but I'll fix it soon later.
If it's confirmed to work, we can set dmix/softvol plugins for default
of snd-powermac driver
At Tue, 29 Mar 2005 21:04:50 +1000,
Benjamin Herrenschmidt wrote:
Yes.
dmix has been around for a while but softvol plugin is very new, you
will need ALSA CVS or the upcoming 1.0.9 release.
dmix currently doesn't work on PPC well but I'll fix it soon later.
If it's confirmed
On Tue, 2005-03-29 at 21:04 +1000, Benjamin Herrenschmidt wrote:
Can the driver advertize in some way what it can do ? depending on the
machine we are running on, it will or will not be able to do HW volume
control... You probably don't want to use softvol in the former case...
dmix by
At Tue, 29 Mar 2005 14:05:08 -0500,
Lee Revell wrote:
On Tue, 2005-03-29 at 21:04 +1000, Benjamin Herrenschmidt wrote:
Can the driver advertize in some way what it can do ? depending on the
machine we are running on, it will or will not be able to do HW volume
control... You probably
On Tue, 2005-03-29 at 21:31 +0200, Takashi Iwai wrote:
Well I don't remember the discussion thread on alsa-devel about this,
but it's a good idea that alsa-lib checks the capability of hw-mixing
and apples dmix only if necessary. (In the case of softvol, it can
check the existence of hw
On Tue, 2005-03-29 at 21:31 +0200, Takashi Iwai wrote:
At Tue, 29 Mar 2005 14:05:08 -0500,
Lee Revell wrote:
On Tue, 2005-03-29 at 21:04 +1000, Benjamin Herrenschmidt wrote:
Can the driver advertize in some way what it can do ? depending on the
machine we are running on, it will or
On Tue, 2005-03-29 at 11:22 +0200, Marcin Dalecki wrote:
No. You didn't get it. I'm taking the view that mixing sound is simply
a task you would typically love to make a DSP firmware do.
However providing a DSP for sound processing at 44kHZ on the same
PCB as an 1GHZ CPU is a ridiculous waste
Lee Revell wrote:
This is the exact line of reasoning that led to Winmodems.
My main issue with winmodems is not so much the software offload, but
rather that the vendors don't release full specs.
If all winmodem manufacturers released full hardware specs, I doubt
people would really complain
On Tue, 2005-03-29 at 17:25 -0600, Chris Friesen wrote:
Lee Revell wrote:
This is the exact line of reasoning that led to Winmodems.
My main issue with winmodems is not so much the software offload, but
rather that the vendors don't release full specs.
If all winmodem manufacturers
On 2005-03-29, at 12:22, Takashi Iwai wrote:
ALSA provides the driver feature in user-space because it's more
flexible, more efficient and safer than doing in kernel. It's
transparent from apps perspective. It really doesn't matter whether
it's in kernel or user space.
Yes because it's that
On 2005-03-30, at 00:13, Lee Revell wrote:
On Tue, 2005-03-29 at 11:22 +0200, Marcin Dalecki wrote:
No. You didn't get it. I'm taking the view that mixing sound is simply
a task you would typically love to make a DSP firmware do.
However providing a DSP for sound processing at 44kHZ on the same
On 2005-03-30, at 01:39, Benjamin Herrenschmidt wrote:
On Tue, 2005-03-29 at 17:25 -0600, Chris Friesen wrote:
Lee Revell wrote:
This is the exact line of reasoning that led to Winmodems.
My main issue with winmodems is not so much the software offload, but
rather that the vendors don't release
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
On 2005-03-29, at 12:22, Takashi Iwai wrote:
ALSA provides the driver feature in user-space because it's more
flexible, more efficient and safer than doing in kernel. It's
transparent from apps perspective. It really doesn't
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
I think your misunderstanding is that you beliieve user-space can't do
RT. It's wrong. See JACK (jackit.sf.net), for example.
I know JACK in and out. It doesn't provide what you claim.
This was just an example, to prove the point
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
I think your misunderstanding is that you beliieve user-space can't do
RT. It's wrong. See JACK (jackit.sf.net), for example.
I know JACK in and out. It doesn't provide what you claim.
Are you implying that He don't know JACK!
On Wed, 2005-03-30 at 03:48 +0200, Marcin Dalecki wrote:
On 2005-03-30, at 01:39, Benjamin Herrenschmidt wrote:
Look at the pile of junk that are most winmodem driver implementations,
nothing I want to see in the kernel ever. Those things should be in
userland.
You are joking? Linux IS
On Mon, 2005-03-28 at 22:36 -0500, Lee Revell wrote:
> On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
> > It seems that Apple's driver has an in-kernel framework for doing volume
> > control, mixing, and other horrors right in the kernel, in temporary
> > buffers, just before
On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
> It seems that Apple's driver has an in-kernel framework for doing volume
> control, mixing, and other horrors right in the kernel, in temporary
> buffers, just before they get DMA'ed (gack !)
>
> I want to avoid something like
On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
It seems that Apple's driver has an in-kernel framework for doing volume
control, mixing, and other horrors right in the kernel, in temporary
buffers, just before they get DMA'ed (gack !)
I want to avoid something like that.
On Mon, 2005-03-28 at 22:36 -0500, Lee Revell wrote:
On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
It seems that Apple's driver has an in-kernel framework for doing volume
control, mixing, and other horrors right in the kernel, in temporary
buffers, just before they get
On Mon, 2005-03-28 at 03:42 +0200, Andrea Arcangeli wrote:
> On Mon, Mar 28, 2005 at 09:42:00AM +1000, Benjamin Herrenschmidt wrote:
> > suggest I just don't do any control ? Or should I implement a double
> > buffer scheme with software gain as well in the kernel driver ?
>
> I recall to have
On Mon, Mar 28, 2005 at 09:42:00AM +1000, Benjamin Herrenschmidt wrote:
> suggest I just don't do any control ? Or should I implement a double
> buffer scheme with software gain as well in the kernel driver ?
I recall to have sometime clicked on volume controls that weren't
hardware related, I
Hi Takashi !
I'm looking into adding proper sound support for the Mac Mini. The
problem is that from what I've seen (Apple driver is only partially
opensource nowadays it seems, and the latest darwin drop is both
incomplete and doesn't build), that beast only has a fixed function D->A
converter,
Hi Takashi !
I'm looking into adding proper sound support for the Mac Mini. The
problem is that from what I've seen (Apple driver is only partially
opensource nowadays it seems, and the latest darwin drop is both
incomplete and doesn't build), that beast only has a fixed function D-A
converter,
On Mon, Mar 28, 2005 at 09:42:00AM +1000, Benjamin Herrenschmidt wrote:
suggest I just don't do any control ? Or should I implement a double
buffer scheme with software gain as well in the kernel driver ?
I recall to have sometime clicked on volume controls that weren't
hardware related, I
On Mon, 2005-03-28 at 03:42 +0200, Andrea Arcangeli wrote:
On Mon, Mar 28, 2005 at 09:42:00AM +1000, Benjamin Herrenschmidt wrote:
suggest I just don't do any control ? Or should I implement a double
buffer scheme with software gain as well in the kernel driver ?
I recall to have sometime
50 matches
Mail list logo
