Hi!
> >Today both OSS and ALSA teams have to spend significant
> >amounts of time in emulating the "alien" APIs. Making
> >OSS and ALSA to co-exist will require some work in both
> >sides but that should be nothing when compared to the
> >effort required for emulation.
>
...
> In Linux we
Hi!
> >
> > Soft mixing is actually the biggest issue because if you had
> > generalized soft-mixing in the kernel-visible audio ports[1] you would
> > win two things:
> >
> > - programs could use the OSS API without interfering with the ALSA one
> > or which each other
>
> This works with
On Sat, Jul 07, 2007 at 02:41:05AM +, William Pitcock wrote:
> The most fucked up thing that I can think of about the current state of
> affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's
> software mixing in kernel space. The applications never even know about
> it.
On Sat, Jul 07, 2007 at 02:41:05AM +, William Pitcock wrote:
The most fucked up thing that I can think of about the current state of
affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's
software mixing in kernel space. The applications never even know about
it.
Hi!
Today both OSS and ALSA teams have to spend significant
amounts of time in emulating the alien APIs. Making
OSS and ALSA to co-exist will require some work in both
sides but that should be nothing when compared to the
effort required for emulation.
...
In Linux we typically do not
Hi!
Soft mixing is actually the biggest issue because if you had
generalized soft-mixing in the kernel-visible audio ports[1] you would
win two things:
- programs could use the OSS API without interfering with the ALSA one
or which each other
This works with aoss.
If people
On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote:
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
I know this may sound kind of stupid, but how about not deprecating either,
and fully supporting both sound systems? Maybe we can get them to work
together, and the distro or user can
On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote:
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
I know this may sound kind of stupid, but how about not deprecating either,
and fully supporting both sound systems? Maybe we can get them to work
together, and the distro or user can
On Wed, 4 Jul 2007, Adrian Bunk wrote:
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
I know this may sound kind of stupid, but how about not deprecating either,
and fully supporting both sound systems? Maybe we can get them to work
together, and the distro or user can choose whether
On Wed, 4 Jul 2007, Adrian Bunk wrote:
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
I know this may sound kind of stupid, but how about not deprecating either,
and fully supporting both sound systems? Maybe we can get them to work
together, and the distro or user can choose whether
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>
> I know this may sound kind of stupid, but how about not deprecating either,
> and fully supporting both sound systems? Maybe we can get them to work
> together, and the distro or user can choose whether they would like to use
> alsa or
Tomasz Kłoczko wrote:
Few dayas ago OSS source code was oppened uder CDDL for Solaris and
GLPv2 for Linux:
http://www.opensound.com/press/2007/oss-gpl-cddl.txt
So this source without problems code can be integragrated in Linus
tree and after this Linux can provide much better soud supoport
Tomasz Kłoczko wrote:
Few dayas ago OSS source code was oppened uder CDDL for Solaris and
GLPv2 for Linux:
http://www.opensound.com/press/2007/oss-gpl-cddl.txt
So this source without problems code can be integragrated in Linus
tree and after this Linux can provide much better soud supoport
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
I know this may sound kind of stupid, but how about not deprecating either,
and fully supporting both sound systems? Maybe we can get them to work
together, and the distro or user can choose whether they would like to use
alsa or oss
> > Well, had a look at what FUSD does. It assumes that the ioctl
> > argument is stuctured according to the command. If all OSS ioctls are
> > like that, then fine, fuse can support it properly.
> >
> > The drawback of this is that ioctls which aren't structured properly
> > could cause weird
On Friday 29 June 2007, Miklos Szeredi wrote:
> > > > Not as if it would be hard to add ioctl support to fuse. What fuse
> > > > can't handle is the data argument of ioctl(), so the most it could do
> > > > is give the filesystem a pid (tid) and a virtual address. The
> > > > userspace fs could
On Friday 29 June 2007, Miklos Szeredi wrote:
Not as if it would be hard to add ioctl support to fuse. What fuse
can't handle is the data argument of ioctl(), so the most it could do
is give the filesystem a pid (tid) and a virtual address. The
userspace fs could then get/put the
Well, had a look at what FUSD does. It assumes that the ioctl
argument is stuctured according to the command. If all OSS ioctls are
like that, then fine, fuse can support it properly.
The drawback of this is that ioctls which aren't structured properly
could cause weird failures due
Robert Hancock shaw.ca> writes:
> In the case of S/PDIF output on ice1724 (and probably other cards), it
> would be nice if ALSA defaulted to routing default audio to both the
> S/PDIF and analog ports, as this is what most users would normally
> expect.. The Windows drivers work like that,
> > > Not as if it would be hard to add ioctl support to fuse. What fuse
> > > can't handle is the data argument of ioctl(), so the most it could do
> > > is give the filesystem a pid (tid) and a virtual address. The
> > > userspace fs could then get/put the data through /proc//mem.
> >
> >
> Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > Not as if it would be hard to add ioctl support to fuse. What fuse
> > can't handle is the data argument of ioctl(), so the most it could do
> > is give the filesystem a pid (tid) and a virtual address. The
> > userspace fs could then get/put the
On Fri, 29 Jun 2007 16:56:05 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Not as if it would be hard to add ioctl support to fuse. What fuse
> can't handle is the data argument of ioctl(), so the most it could do
> is give the filesystem a pid (tid) and a virtual address. The
> userspace fs
> I suppose the best way to provide OSS emu is to use something like
> FUSD [similar to the OSS2JACK package] [1] to provide the OSS device
> files and then redirect to user space, so all ALSA pcm devices can
> be used.. Sadly FUSD doesn't really get actively developed anymore
> it seems. And FUSE
Anton Petrusevich wrote:
Is there a tool which can be used to configure .asoundrc?
There is an QT4 based one [1] and a somewhat old KDE based tool [2].
Regards,
Gabriel C
[1] http://sourceforge.net/projects/aplugedit/
[2] http://sourceforge.net/projects/kasound/
-
To unsubscribe from
On Friday 29 June 2007, Anton Petrusevich wrote:
> On Friday 29 June 2007 12:30:54 Florian Schmidt wrote:
> > Sadly it seems pretty much everyone, especially closed source apps get
> > this wrong (but to be fair: loads of open source software gets it wrong,
> > too, ekiga for example).
>
> Isn't
On Thursday 28 June 2007, Adrian Bunk wrote:
> There is also a userspace OSS emulation for ALSA not suffering from
> these problems.
Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to
intercept library calls that open the /dev/dsp devices etc.. This doesn't
always work.
On Friday 29 June 2007 12:30:54 Florian Schmidt wrote:
> Sadly it seems pretty much everyone, especially closed source apps get this
> wrong (but to be fair: loads of open source software gets it wrong, too,
> ekiga for example).
Isn't that because there's a perferct documentation for programming
On Thursday 28 June 2007, Anton Petrusevich wrote:
> > > I have ICE1724, a very good sound card to my taste, works like a charm.
> > > But with ALSA I had a really hard time to configure it properly, wanna
> > > see my .asoundrc?
> >
> > Not particularly. I don't count as a great fan of the config
On Thursday 28 June 2007, Anton Petrusevich wrote:
I have ICE1724, a very good sound card to my taste, works like a charm.
But with ALSA I had a really hard time to configure it properly, wanna
see my .asoundrc?
Not particularly. I don't count as a great fan of the config file syntax
On Thursday 28 June 2007, Adrian Bunk wrote:
There is also a userspace OSS emulation for ALSA not suffering from
these problems.
Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to
intercept library calls that open the /dev/dsp devices etc.. This doesn't
always work.
On Friday 29 June 2007 12:30:54 Florian Schmidt wrote:
Sadly it seems pretty much everyone, especially closed source apps get this
wrong (but to be fair: loads of open source software gets it wrong, too,
ekiga for example).
Isn't that because there's a perferct documentation for programming
On Friday 29 June 2007, Anton Petrusevich wrote:
On Friday 29 June 2007 12:30:54 Florian Schmidt wrote:
Sadly it seems pretty much everyone, especially closed source apps get
this wrong (but to be fair: loads of open source software gets it wrong,
too, ekiga for example).
Isn't that
Anton Petrusevich wrote:
Is there a tool which can be used to configure .asoundrc?
There is an QT4 based one [1] and a somewhat old KDE based tool [2].
Regards,
Gabriel C
[1] http://sourceforge.net/projects/aplugedit/
[2] http://sourceforge.net/projects/kasound/
-
To unsubscribe from
I suppose the best way to provide OSS emu is to use something like
FUSD [similar to the OSS2JACK package] [1] to provide the OSS device
files and then redirect to user space, so all ALSA pcm devices can
be used.. Sadly FUSD doesn't really get actively developed anymore
it seems. And FUSE
On Fri, 29 Jun 2007 16:56:05 +0200
Miklos Szeredi [EMAIL PROTECTED] wrote:
Not as if it would be hard to add ioctl support to fuse. What fuse
can't handle is the data argument of ioctl(), so the most it could do
is give the filesystem a pid (tid) and a virtual address. The
userspace fs could
Not as if it would be hard to add ioctl support to fuse. What fuse
can't handle is the data argument of ioctl(), so the most it could do
is give the filesystem a pid (tid) and a virtual address. The
userspace fs could then get/put the data through /proc/pid/mem.
Hork...
Miklos Szeredi [EMAIL PROTECTED] wrote:
Not as if it would be hard to add ioctl support to fuse. What fuse
can't handle is the data argument of ioctl(), so the most it could do
is give the filesystem a pid (tid) and a virtual address. The
userspace fs could then get/put the data through
Robert Hancock hancockr at shaw.ca writes:
In the case of S/PDIF output on ice1724 (and probably other cards), it
would be nice if ALSA defaulted to routing default audio to both the
S/PDIF and analog ports, as this is what most users would normally
expect.. The Windows drivers work like
Anton Petrusevich wrote:
On Thursday 28 June 2007 17:02:55 you wrote:
Please always use Reply-to-All on this list -- subscribers here like to
also get personal copies.
I am not subscribed to linux-kernel, I am reading it on the web.
I have ICE1724, a very good sound card to my taste, works
On 28 Jun 2007, Adrian Bunk outgrape:
> Linux software not supporting ALSA has becoming quite esoteric.
Indeed. This is why I haven't moaned much (or at all): aoss is ugly,
sure, but you only need it for those rare apps which run for a long time
or while other sounds are playing, on
On 06/28/2007 11:06 PM, Adrian Bunk wrote:
The interesting point is that what you call "internal implementation
details" is much _more_ exposed with the OSS emulation in the kernel
_enabled_.
Why?
Linux software not supporting ALSA has becoming quite esoteric.
But software like mplayer
On Thu, Jun 28, 2007 at 07:30:36PM +0100, Nix wrote:
> On 25 Jun 2007, Adrian Bunk stated:
> > If people often run into this problem it might make sense to deprecate
> > the in-kernel OSS emulation and point people to the userspace emulation
> > instead?
>
> So now people need to know internal
On Thu, Jun 28, 2007 at 04:20:45PM -0400, Lee Revell wrote:
> On 6/28/07, Rene Herman <[EMAIL PROTECTED]> wrote:
>> ALSA has been the Linux soundsystem for a number of years now and as such,
>> an application that runs under Linux and produces sound more and more can
>> be
>> expected to do so
Rene Herman wrote:
Anyways, I suspect at least Takashi Iwai would simply say "no" to
removing or deprecating the in kernel emulation anyway, although it's
not likely to grow features anymore.
Even if he fails to say "no" in such a case, many other people would
stand up and do so :) In
On 6/28/07, Rene Herman <[EMAIL PROTECTED]> wrote:
ALSA has been the Linux soundsystem for a number of years now and as such,
an application that runs under Linux and produces sound more and more can be
expected to do so using the Linux API. The only reason it _can_ be seen as a
detail is due to
On 06/28/2007 08:30 PM, Nix wrote:
On 25 Jun 2007, Adrian Bunk stated:
If people often run into this problem it might make sense to deprecate
the in-kernel OSS emulation and point people to the userspace emulation
instead?
So now people need to know internal implementation details like if a
On 06/28/2007 09:33 PM, Tomasz Kłoczko wrote:
On 06/28/2007 06:34 PM, Anton Petrusevich wrote:
Do you have an SPDIF out? If you don't then you don't need .asoundrc
of course.
I do on a number of cards, although being without sensible equipment
(other than other soundcards) with an S/PDIF
On Thu, 28 Jun 2007, Rene Herman wrote:
On 06/28/2007 06:34 PM, Anton Petrusevich wrote:
Do you have an SPDIF out? If you don't then you don't need .asoundrc of
course.
I do on a number of cards, although being without sensible equipment (other
than other soundcards) with an S/PDIF _in_ I
On 06/28/2007 06:34 PM, Anton Petrusevich wrote:
Do you have an SPDIF out? If you don't then you don't need .asoundrc of
course.
I do on a number of cards, although being without sensible equipment (other
than other soundcards) with an S/PDIF _in_ I don't actually use it for more
than
On 25 Jun 2007, Adrian Bunk stated:
> If people often run into this problem it might make sense to deprecate
> the in-kernel OSS emulation and point people to the userspace emulation
> instead?
So now people need to know internal implementation details like if a
program uses ALSA or OSS
On Thu, 2007-06-28 at 18:34 +0200, Anton Petrusevich wrote:
> > Please always use Reply-to-All on this list -- subscribers here like to
> > also get personal copies.
>
> I am not subscribed to linux-kernel, I am reading it on the web.
Then please subscribe just for the time you want to
On Thursday 28 June 2007 17:02:55 you wrote:
> Please always use Reply-to-All on this list -- subscribers here like to
> also get personal copies.
I am not subscribed to linux-kernel, I am reading it on the web.
> > I have ICE1724, a very good sound card to my taste, works like a charm.
> > But
On 06/28/2007 02:42 PM, Anton Petrusevich wrote:
Please always use Reply-to-All on this list -- subscribers here like to also
get personal copies.
I have ICE1724, a very good sound card to my taste, works like a charm.
But with ALSA I had a really hard time to configure it properly, wanna
Our developers chose ALSA over OSS as the sound API for a VOIP-like
fullduplex application and one of the reasons was API - OSS mixer API
was not flexible enough (something to do with separating muting and
volume control IIRC).
--
Meelis Roos
-
To unsubscribe from this list: send the line
On 06/28/2007 01:50 PM, Tomasz Kłoczko wrote:
If can I join .. (again)
Welcome...
After upgrade to skype 1.4.x all sound output in skype I have only in
left channel. Serching for skype+left+channel on google shows many
people have this kind problem :>
This would seem to be a (fairly,
On 06/28/2007 05:04 AM, Patrick Draper wrote:
Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss
means software mixing is working correctly for your ALSA setup. The
only thing you should do is _use_ ALSA (natively) and not its OSS
emulation so you can
Tomasz Kłoczko wrote:
On Wed, 27 Jun 2007, Patrick Draper wrote:
Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss means
software mixing is working correctly for your ALSA setup. The only thing
you should do is _use_ ALSA (natively) and not its
On Wed, 27 Jun 2007, Lee Revell wrote:
On 6/26/07, Andreas Hartmetz <[EMAIL PROTECTED]> wrote:
Why not put the whole sound system in userland? It has been done before.
Sound
is just not performance critical at all and it's almost never mission
critical.
There are dozens of companies selling
On Wed, 27 Jun 2007, Patrick Draper wrote:
Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss means
software mixing is working correctly for your ALSA setup. The only thing
you should do is _use_ ALSA (natively) and not its OSS emulation so you can
drop
On 06/28/2007 04:28 AM, Rene Herman wrote:
On 06/28/2007 03:58 AM, Rene Herman wrote:
to figure it out. If you need to specify an ALSA device somewhere, make
sure it's not the old "hw:0" but "default" (or "default:0" for the
first card, "default:1" for the second, ...). The "hw:N" devices
On 06/28/2007 04:28 AM, Rene Herman wrote:
On 06/28/2007 03:58 AM, Rene Herman wrote:
to figure it out. If you need to specify an ALSA device somewhere, make
sure it's not the old hw:0 but default (or default:0 for the
first card, default:1 for the second, ...). The hw:N devices don't
do
On Wed, 27 Jun 2007, Patrick Draper wrote:
Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss means
software mixing is working correctly for your ALSA setup. The only thing
you should do is _use_ ALSA (natively) and not its OSS emulation so you can
drop
On Wed, 27 Jun 2007, Lee Revell wrote:
On 6/26/07, Andreas Hartmetz [EMAIL PROTECTED] wrote:
Why not put the whole sound system in userland? It has been done before.
Sound
is just not performance critical at all and it's almost never mission
critical.
There are dozens of companies selling
Tomasz Kłoczko wrote:
On Wed, 27 Jun 2007, Patrick Draper wrote:
Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss means
software mixing is working correctly for your ALSA setup. The only thing
you should do is _use_ ALSA (natively) and not its
On 06/28/2007 05:04 AM, Patrick Draper wrote:
Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss
means software mixing is working correctly for your ALSA setup. The
only thing you should do is _use_ ALSA (natively) and not its OSS
emulation so you can
On 06/28/2007 01:50 PM, Tomasz Kłoczko wrote:
If can I join .. (again)
Welcome...
After upgrade to skype 1.4.x all sound output in skype I have only in
left channel. Serching for skype+left+channel on google shows many
people have this kind problem :
This would seem to be a (fairly, it's
Our developers chose ALSA over OSS as the sound API for a VOIP-like
fullduplex application and one of the reasons was API - OSS mixer API
was not flexible enough (something to do with separating muting and
volume control IIRC).
--
Meelis Roos
-
To unsubscribe from this list: send the line
On 06/28/2007 02:42 PM, Anton Petrusevich wrote:
Please always use Reply-to-All on this list -- subscribers here like to also
get personal copies.
I have ICE1724, a very good sound card to my taste, works like a charm.
But with ALSA I had a really hard time to configure it properly, wanna
On Thursday 28 June 2007 17:02:55 you wrote:
Please always use Reply-to-All on this list -- subscribers here like to
also get personal copies.
I am not subscribed to linux-kernel, I am reading it on the web.
I have ICE1724, a very good sound card to my taste, works like a charm.
But with
On Thu, 2007-06-28 at 18:34 +0200, Anton Petrusevich wrote:
Please always use Reply-to-All on this list -- subscribers here like to
also get personal copies.
I am not subscribed to linux-kernel, I am reading it on the web.
Then please subscribe just for the time you want to participate to
On 25 Jun 2007, Adrian Bunk stated:
If people often run into this problem it might make sense to deprecate
the in-kernel OSS emulation and point people to the userspace emulation
instead?
So now people need to know internal implementation details like if a
program uses ALSA or OSS interfaces
On 06/28/2007 06:34 PM, Anton Petrusevich wrote:
Do you have an SPDIF out? If you don't then you don't need .asoundrc of
course.
I do on a number of cards, although being without sensible equipment (other
than other soundcards) with an S/PDIF _in_ I don't actually use it for more
than
On Thu, 28 Jun 2007, Rene Herman wrote:
On 06/28/2007 06:34 PM, Anton Petrusevich wrote:
Do you have an SPDIF out? If you don't then you don't need .asoundrc of
course.
I do on a number of cards, although being without sensible equipment (other
than other soundcards) with an S/PDIF _in_ I
On 06/28/2007 09:33 PM, Tomasz Kłoczko wrote:
On 06/28/2007 06:34 PM, Anton Petrusevich wrote:
Do you have an SPDIF out? If you don't then you don't need .asoundrc
of course.
I do on a number of cards, although being without sensible equipment
(other than other soundcards) with an S/PDIF
On 06/28/2007 08:30 PM, Nix wrote:
On 25 Jun 2007, Adrian Bunk stated:
If people often run into this problem it might make sense to deprecate
the in-kernel OSS emulation and point people to the userspace emulation
instead?
So now people need to know internal implementation details like if a
On 6/28/07, Rene Herman [EMAIL PROTECTED] wrote:
ALSA has been the Linux soundsystem for a number of years now and as such,
an application that runs under Linux and produces sound more and more can be
expected to do so using the Linux API. The only reason it _can_ be seen as a
detail is due to
Rene Herman wrote:
Anyways, I suspect at least Takashi Iwai would simply say no to
removing or deprecating the in kernel emulation anyway, although it's
not likely to grow features anymore.
Even if he fails to say no in such a case, many other people would
stand up and do so :) In Linux we
On Thu, Jun 28, 2007 at 04:20:45PM -0400, Lee Revell wrote:
On 6/28/07, Rene Herman [EMAIL PROTECTED] wrote:
ALSA has been the Linux soundsystem for a number of years now and as such,
an application that runs under Linux and produces sound more and more can
be
expected to do so using the
On Thu, Jun 28, 2007 at 07:30:36PM +0100, Nix wrote:
On 25 Jun 2007, Adrian Bunk stated:
If people often run into this problem it might make sense to deprecate
the in-kernel OSS emulation and point people to the userspace emulation
instead?
So now people need to know internal
On 06/28/2007 11:06 PM, Adrian Bunk wrote:
The interesting point is that what you call internal implementation
details is much _more_ exposed with the OSS emulation in the kernel
_enabled_.
Why?
Linux software not supporting ALSA has becoming quite esoteric.
But software like mplayer
On 28 Jun 2007, Adrian Bunk outgrape:
Linux software not supporting ALSA has becoming quite esoteric.
Indeed. This is why I haven't moaned much (or at all): aoss is ugly,
sure, but you only need it for those rare apps which run for a long time
or while other sounds are playing, on
Anton Petrusevich wrote:
On Thursday 28 June 2007 17:02:55 you wrote:
Please always use Reply-to-All on this list -- subscribers here like to
also get personal copies.
I am not subscribed to linux-kernel, I am reading it on the web.
I have ICE1724, a very good sound card to my taste, works
On Wed, 2007-06-27 at 22:04 -0500, Patrick Draper wrote:
> Rene Herman wrote:
> > So -- the fact that mixing actually works for you when using libaoss
> > means software mixing is working correctly for your ALSA setup. The only
> > thing you should do is _use_ ALSA (natively) and not its OSS
On 6/26/07, Andreas Hartmetz <[EMAIL PROTECTED]> wrote:
Why not put the whole sound system in userland? It has been done before. Sound
is just not performance critical at all and it's almost never mission
critical.
There are dozens of companies selling Linux powered professional audio
gear,
On 6/27/07, Patrick Draper <[EMAIL PROTECTED]> wrote:
Rene Herman wrote:
> So -- the fact that mixing actually works for you when using libaoss
> means software mixing is working correctly for your ALSA setup. The only
> thing you should do is _use_ ALSA (natively) and not its OSS emulation
> so
Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss
means software mixing is working correctly for your ALSA setup. The only
thing you should do is _use_ ALSA (natively) and not its OSS emulation
so you can drop the library preload.
Cool. How do I go about
On 06/28/2007 03:58 AM, Rene Herman wrote:
to figure it out. If you need to specify an ALSA device somewhere, make
sure it's not the old "hw:0" but "default" (or "default:0" for the first
card, "default:1" for the second, ...). The "hw:N" devices don't do
mixing.
Slight correction/expansion
On 06/28/2007 02:18 AM, Patrick Draper wrote:
Please always use Reply-to-All on this list -- subscribers here like to also
get personal copies.
Rene Herman wrote:
KDE has finally dropped aRts from KDE4 and, again, ALSA has been
mixing by default for some time now so we're talking history
Rene Herman wrote:
KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing
by default for some time now so we're talking history anyway. You want
mixing on your card? You got it.
I've been following this discussion with some interest, to learn more
about ALSA. I've been
On 06/27/2007 09:10 PM, Andreas Hartmetz wrote:
I don't like random applications blocking my sound card.
So don't use random applications.
I imitated the style of the mail I replied to. Besides, choosing apps
based on sound system is retarded if you wanted to indicate that this
should be
> > I don't like random applications blocking my sound card.
>
> So don't use random applications.
>
I imitated the style of the mail I replied to. Besides, choosing apps based on
sound system is retarded if you wanted to indicate that this should be done
more often or something.
> > You are
On 06/27/2007 06:25 PM, Andreas Hartmetz wrote:
I don't like random applications blocking my sound card.
So don't use random applications.
You are concerned about your precious audio quality? Me too. Most people,
however, are using god-awful plastic speakers for twenty euros and shitty
> > The track record of ALSA for me goes like this:
> > - dmix finally started working automatically (at least on my Kubuntu
> > system) about one year ago, about five years after everybody could see
> > that this was badly needed.
>
> I don't remember when it happened, but I do remember
Takashi Iwai wrote:
> At Tue, 26 Jun 2007 12:25:16 -0400,
> Wakko Warner wrote:
> > I have a motherboard with an intel chipset and onboard audio. I have a
> > problem with alsa. There's no pcm* files in /proc/asound/card0.
>
> Set CONFIG_SND_VERBOSE_PROCFS=y.
GAH! Thanks, I didn't think I
Takashi Iwai wrote:
At Tue, 26 Jun 2007 12:25:16 -0400,
Wakko Warner wrote:
I have a motherboard with an intel chipset and onboard audio. I have a
problem with alsa. There's no pcm* files in /proc/asound/card0.
Set CONFIG_SND_VERBOSE_PROCFS=y.
GAH! Thanks, I didn't think I needed it
The track record of ALSA for me goes like this:
- dmix finally started working automatically (at least on my Kubuntu
system) about one year ago, about five years after everybody could see
that this was badly needed.
I don't remember when it happened, but I do remember that I
On 06/27/2007 06:25 PM, Andreas Hartmetz wrote:
I don't like random applications blocking my sound card.
So don't use random applications.
You are concerned about your precious audio quality? Me too. Most people,
however, are using god-awful plastic speakers for twenty euros and shitty
I don't like random applications blocking my sound card.
So don't use random applications.
I imitated the style of the mail I replied to. Besides, choosing apps based on
sound system is retarded if you wanted to indicate that this should be done
more often or something.
You are concerned
On 06/27/2007 09:10 PM, Andreas Hartmetz wrote:
I don't like random applications blocking my sound card.
So don't use random applications.
I imitated the style of the mail I replied to. Besides, choosing apps
based on sound system is retarded if you wanted to indicate that this
should be
Rene Herman wrote:
KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing
by default for some time now so we're talking history anyway. You want
mixing on your card? You got it.
I've been following this discussion with some interest, to learn more
about ALSA. I've been
1 - 100 of 214 matches
Mail list logo
