17 Dec
2009
17 Dec
'09
7:47 a.m.
Lennart Poettering:
On Fri, 11.12.09 14:24, Kjetil S. Matheussen (k.s.matheussen(a)notam02.no) wrote:
No. Not providing mixing for all devices is a design fault
in alsa. I'm going to install OSS as soon as I get time.
After about 10 years of frustration, I'm a
bit tired of alsa.
Does anyone know if OSS supports proper software mixing?
Is the alsa emulation working somewhat okay?
Are there any problems configuring the machine to use more than one card?
One should note that OSS on Linux is a dead-end. The latest two Fedora
releases have disabled kernel support for the OSS APIs by default, and
Ubuntu is expected to do this now too. (or already did?)
Also, note that the big distributors have folks working on ALSA. OTOH
nobody who has any stakes in Linux supports OSS anymore or even has
people working on it.
17 Dec
17 Dec
8:01 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
On Thursday 17 December 2009 12:47:42 Kjetil S. Matheussen wrote:
No. Not providing mixing for all devices is a design
fault
in alsa. I'm going to install OSS as soon as I get time.
Actually alsa is providing dmix for quite a long time already. And made it the
default-device for an almost as long time. Only distributions didn't pick it
up until lately.
Arnold (never really impacted by dmix as all my cards support hardware-
mixing:)
8:29 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
On Thu, Dec 17, 2009 at 6:47 AM, Kjetil S. Matheussen
<k.s.matheussen(a)notam02.no> wrote:
No. Not providing mixing for all devices is a design
fault
in alsa. I'm going to install OSS as soon as I get time.
Kjetil, although you're absolutely welcome to your own opinions on
this, I would note two things:
1) ALSA has long provided "dmix" user space mixing without a server.
Its a very, very clever
solution that is, unfortunately, so clever that it often doesn't
work for the most demanding
situations. For normal desktop use, it has always worked well.
However, as well as it works
simply goes to emphasize all the desirable details of a desktop
sound system that dmix
by itself does not provide: per-app volume control, easy device
switching, and more. As
a result ...
2) many people would say that its not ALSA's job to provide this
kind of functionality but
instead to act as a kind of HAL for audio. The job of mixing
should (and can) be done
by a user-space implementation (PulseAudio or JACK depending on
your workflow
needs), and ALSA can simply be "the device drivers". This is
certainly how the
audio ecosystem is shaping up on Linux now, particularly with
the increasing
emphasis among those paying for system development because their work
generally involves low power mobile devices where the desktop
issues are absent.
--p
8:40 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
It's also true to say that elsewhere, on Windows, if you want to have
low-latency, you also loose the software mixer. AFAIK ASIO drivers and
KS implementations are single-client like alsa.
To me, it makes perfect sense to have alsa as a HAL, and get people
using pulseaudio or jack at application level.
Victor
On 17 Dec 2009, at 12:29, Paul Davis wrote:
On Thu, Dec 17, 2009 at 6:47 AM, Kjetil S. Matheussen
<k.s.matheussen(a)notam02.no> wrote:
No. Not providing mixing for all devices is a
design fault
in alsa. I'm going to install OSS as soon as I get time.
Kjetil, although you're absolutely welcome to your own opinions on
this, I would note two things:
1) ALSA has long provided "dmix" user space mixing without a server.
Its a very, very clever
solution that is, unfortunately, so clever that it often doesn't
work for the most demanding
situations. For normal desktop use, it has always worked well.
However, as well as it works
simply goes to emphasize all the desirable details of a desktop
sound system that dmix
by itself does not provide: per-app volume control, easy device
switching, and more. As
a result ...
2) many people would say that its not ALSA's job to provide this
kind of functionality but
instead to act as a kind of HAL for audio. The job of mixing
should (and can) be done
by a user-space implementation (PulseAudio or JACK depending on
your workflow
needs), and ALSA can simply be "the device drivers". This is
certainly how the
audio ecosystem is shaping up on Linux now, particularly with
the increasing
emphasis among those paying for system development because
their work
generally involves low power mobile devices where the desktop
issues are absent.
--p
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
8:52 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
On Thu, 17 Dec 2009, Victor Lazzarini wrote:
It's also true to say that elsewhere, on Windows,
if you want to have
low-latency, you also loose the software mixer. AFAIK ASIO drivers and KS
implementations are single-client like alsa.
As far as my current experience with XP SP3 goes, this is not correct.
Mixing works just fine, even when using ASIO. Maybe you have to start
the asio program first though, I don't know. But still, there's no
reason why you shouldn't have a global option, lets say 256 frames
48000Hz, that everything mixes down to, and then software which needs
hardcore low-level performance must obey to that setting.
To me, it makes perfect sense to have alsa as a HAL,
and get people using
pulseaudio or jack at application level.
Something which is unnecessarily complicated can not make perfect sense.
8:56 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
Well, with my ASIO devices if a program is using that audio card via
ASIO, other programs can't access it. It may well vary from driver to
driver then.
Victor
On 17 Dec 2009, at 12:52, Kjetil S. Matheussen wrote:
On Thu, 17 Dec 2009, Victor Lazzarini wrote:
It's also true to say that elsewhere, on
Windows, if you want to
have low-latency, you also loose the software mixer. AFAIK ASIO
drivers and KS implementations are single-client like alsa.
As far as my current experience with XP SP3 goes, this is not correct.
Mixing works just fine, even when using ASIO. Maybe you have to start
the asio program first though, I don't know. But still, there's no
reason why you shouldn't have a global option, lets say 256 frames
48000Hz, that everything mixes down to, and then software which needs
hardcore low-level performance must obey to that setting.
To me, it makes perfect sense to have alsa as a
HAL, and get people
using pulseaudio or jack at application level.
Something which is unnecessarily complicated can not make perfect
sense.
10:03 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
On Thu, 17.12.09 13:52, Kjetil S. Matheussen (k.s.matheussen(a)notam02.no) wrote:
Mixing works just fine, even when using ASIO. Maybe
you have to start
the asio program first though, I don't know. But still, there's no
reason why you shouldn't have a global option, lets say 256 frames
48000Hz, that everything mixes down to, and then software which needs
hardcore low-level performance must obey to that setting.
Uh, that's a great way to burn your battery.
If you care about more than pro audio, then you want to dynamically
adjust the sleep times based on the requirements of the clients
connected. That means you cannot use fixed sized hardware fragments
anymore, but need to schedule audio more dynamically using system
timers.
This in fact is where most of the complexity in systems such as
PulseAudio stems from.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:14 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
On Thu, Dec 17, 2009 at 9:02 AM, Lennart Poettering <mzynq(a)0pointer.de> wrote:
On Thu, 17.12.09 13:52, Kjetil S. Matheussen
(k.s.matheussen(a)notam02.no) wrote:
and before the accusations start flying, this is also how CoreAudio
works on OS X (and even more so in the iPhone "version" of CoreAudio,
which doesn't a lot like CoreAudio at all).
--p
Mixing works just fine, even when using ASIO.
Maybe you have to start
the asio program first though, I don't know. But still, there's no
reason why you shouldn't have a global option, lets say 256 frames
48000Hz, that everything mixes down to, and then software which needs
hardcore low-level performance must obey to that setting.
Uh, that's a great way to burn your battery.
If you care about more than pro audio, then you want to dynamically
adjust the sleep times based on the requirements of the clients
connected. That means you cannot use fixed sized hardware fragments
anymore, but need to schedule audio more dynamically using system
timers.
This in fact is where most of the complexity in systems such as
PulseAudio stems from.
10:46 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
On Thu, 17.12.09 09:14, Paul Davis (paul(a)linuxaudiosystems.com) wrote:
And Vista apparently too as it seems.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
If you care
about more than pro audio, then you want to dynamically
adjust the sleep times based on the requirements of the clients
connected. That means you cannot use fixed sized hardware fragments
anymore, but need to schedule audio more dynamically using system
timers.
This in fact is where most of the complexity in systems such as
PulseAudio stems from.
and before the accusations start flying, this is also how CoreAudio
works on OS X (and even more so in the iPhone "version" of CoreAudio,
which doesn't a lot like CoreAudio at all).
10:58 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
Through which API? I not sure I understand audio IO on Vista, with the
concurrent existence of several APIs. Never mind, perhaps this is a
bit OT in a Linux Audio list...
Victor
On 17 Dec 2009, at 14:45, Lennart Poettering wrote:
On Thu, 17.12.09 09:14, Paul Davis
(paul(a)linuxaudiosystems.com) wrote:
And Vista apparently too as it seems.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
If you
care about more than pro audio, then you want to dynamically
adjust the sleep times based on the requirements of the clients
connected. That means you cannot use fixed sized hardware fragments
anymore, but need to schedule audio more dynamically using system
timers.
This in fact is where most of the complexity in systems such as
PulseAudio stems from.
and before the accusations start flying, this is also how CoreAudio
works on OS X (and even more so in the iPhone "version" of CoreAudio,
which doesn't a lot like CoreAudio at all). 
3:43 p.m.
New subject: Anyone have experience with OSS (3 or 4)?
On 12/17/2009 04:58 PM, Victor Lazzarini wrote:
Through which API? I not sure I understand audio IO on
Vista, with the
concurrent existence of several APIs. Never mind, perhaps this is a
bit OT in a Linux Audio list...
There's WASAPI and rest is practically emulated on top of it.
The good side is that there's practically one API where the programmer
can choose if he wants to do casual audio with mixing and samplerate
conversion (always floats) or he can talk directly to the hardware in
native sample format if needed. There is also possibility to pipeline
and connect different audio elements there (like effects etc).
So it's kind of ALSA, jack and pulseaudio combined behind one API...
4:20 p.m.
New subject: Anyone have experience with OSS (3 or 4)?
On Thu, Dec 17, 2009 at 2:43 PM, Jussi Laako <jussi(a)sonarnerd.net> wrote:
On 12/17/2009 04:58 PM, Victor Lazzarini wrote:
yeah, they actually took a lot of good lessons from CoreAudio, which
has been doing all that for years.
Through which API? I not sure I understand audio
IO on Vista, with the
concurrent existence of several APIs. Never mind, perhaps this is a
bit OT in a Linux Audio list...
There's WASAPI and rest is practically emulated on top of it.
The good side is that there's practically one API where the programmer
can choose if he wants to do casual audio with mixing and samplerate
conversion (always floats) or he can talk directly to the hardware in
native sample format if needed. There is also possibility to pipeline
and connect different audio elements there (like effects etc).
So it's kind of ALSA, jack and pulseaudio combined behind one API...
5:25 p.m.
New subject: Anyone have experience with OSS (3 or 4)?
On 12/17/2009 10:20 PM, Paul Davis wrote:
yeah, they actually took a lot of good lessons from
CoreAudio, which
has been doing all that for years.
I have failed to find native sample format direct hardware access
methods (mixing and samplerate conversion disabled) from CoreAudio, but
maybe I just haven't looked closely enough or something...
7:21 p.m.
New subject: Anyone have experience with OSS (3 or 4)?
Even more OT: is WASAPI supported by PortAudio?
Victor
----- Original Message -----
From: "Jussi Laako" <jussi(a)sonarnerd.net>
To: <linux-audio-dev(a)lists.linuxaudio.org>
Sent: Thursday, December 17, 2009 7:43 PM
Subject: Re: [LAD] Anyone have experience with OSS (3 or 4)?
On 12/17/2009 04:58 PM, Victor Lazzarini wrote:
Through which API? I not sure I understand audio
IO on Vista, with the
concurrent existence of several APIs. Never mind, perhaps this is a
bit OT in a Linux Audio list...
There's WASAPI and rest is practically emulated on top of it.
The good side is that there's practically one API where the programmer
can choose if he wants to do casual audio with mixing and samplerate
conversion (always floats) or he can talk directly to the hardware in
native sample format if needed. There is also possibility to pipeline
and connect different audio elements there (like effects etc).
So it's kind of ALSA, jack and pulseaudio combined behind one API...
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
7:35 p.m.
New subject: Anyone have experience with OSS (3 or 4)?
A quick look at WASAPI reference and examples seems to indicate it uses a
blocking IO method. Is there
a callback mode? Sorry for all of these OT questions, but I got really
curious. Can WASAPI match Linux and
OSX levels of latency?
Victor
----- Original Message -----
From: "Jussi Laako" <jussi(a)sonarnerd.net>
To: <linux-audio-dev(a)lists.linuxaudio.org>
Sent: Thursday, December 17, 2009 7:43 PM
Subject: Re: [LAD] Anyone have experience with OSS (3 or 4)?
On 12/17/2009 04:58 PM, Victor Lazzarini wrote:
Through which API? I not sure I understand audio
IO on Vista, with the
concurrent existence of several APIs. Never mind, perhaps this is a
bit OT in a Linux Audio list...
There's WASAPI and rest is practically emulated on top of it.
The good side is that there's practically one API where the programmer
can choose if he wants to do casual audio with mixing and samplerate
conversion (always floats) or he can talk directly to the hardware in
native sample format if needed. There is also possibility to pipeline
and connect different audio elements there (like effects etc).
So it's kind of ALSA, jack and pulseaudio combined behind one API...
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
18 Dec
18 Dec
3:32 a.m.
New subject: Anyone have experience with OSS (3 or 4)?
I don't think we should take this OT discussion any further on the list.
On 12/18/2009 01:35 AM, victor wrote:
A quick look at WASAPI reference and examples seems to
indicate it uses
a blocking IO method. Is there
a callback mode? Sorry for all of these OT questions, but I got really
curious.
Depending on used mode it can be used also through blocking method, but
generally it doesn't require blocking in any mode.
Can WASAPI match Linux and OSX levels of latency?
I haven't done such comparisons on equal hardware. It can achieve same
performance as ASIO.
5450
days inactive
5451
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
7 participants
participants (7)
-
Arnold Krille -
Jussi Laako -
Kjetil S. Matheussen -
Lennart Poettering -
Paul Davis -
victor -
Victor Lazzarini