14 Jun
2009
14 Jun
'09
1:15 p.m.
Now that I've gotten a pretty clear picture of the concensus about
PulseAudio, I wondered about some of the other (new and old) sound
facilities in Linux, and specifically wondered if being on a system like
Gentoo where one can turn off build-time support for these things is a
good idea. So...
PortAudio:
From what I can see, this doesn't do much. It
seems to provide an API
of sorts that unifies Linux sound with sound on other
operating systems.
(For example, FreeBSD supports PortAudio, even though its an OSS-based
system.) Then again, I thought Alsa's OSS emulation provided a
'/dev/dsp' that did that already. Anyway...
Is this bad? Has anyone had nearly the nightmares with
PortAudio presence in a DAW system that's described from users of newer
systems with PulseAudio? I don't want to incriminate it just because
its name is similar. (Though I do find myself calling PortAudio
"PulseAudio" by accident a lot. They really could have found a better
name for that...)
Gentoo has a USE flag to disable PortAudio, but I hesitate to do
so if most of the apps these days are taking its presence as a given. I
don't want to diverge from what's perceived as "normal" upstream more
than necessary to achieve good results.
Esound ("esd"):
This is truly 90's technology that won't die, and we all know that.
The question is, how much of an assumption is it in the apps (and in the
Gnome desktop) to the extent that if it weren't there, there would be
problems? Is it safe on a Gentoo system to globally ban build support
for ESD? Sure, Alsa has its own mixer, but will the apps just
transparently use it if ESD isn't around? This is really the gist of
all my questions here: We know there are daemons we don't like. But
which ones are safe to actually kill, and which ones do we still sadly
depend on for something or other?
Arts ("artsd"):
I already have some doubts about eliminating this one, at least in any
system that hopes to have a KDE desktop available. Even if we don't
need it per se, KDE seems (at least to a naive user like me) to be
deeply wedded to it. There are even direct mentions of artsd setup in
some of the audio setup panels of the KDE Control Panel. Does banning
Artsd support equal losing all desktop audio support in KDE? It looks
like it might...experiences?
I guess what I'm thinking is that it'd be nice to do a build in which
everything but Alsa and Jack is banished to hell, but I'm wondering if
that will leave some programs at a loss to find a mixer at all, and thus
without sound. Ideally, all sound apps, regardless of what target
they're expecting, ought to be able to transparently find the Alsa
mixer, and multiplex with other apps to share access with it
simultaneously, also without special setup.
Does that work?
(I'd even put up with artsd if I had to, since KDE seems to assume it,
and since it doesn't seem to cause major problems...)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
14 Jun
14 Jun
1:58 p.m.
Brent Busby wrote:
PortAudio:
Isn't PortAudio an API... not a sound server?
Arts ("artsd"):
I already have some doubts about eliminating this one, at least in any
system that hopes to have a KDE desktop available. Even if we don't
need it per se, KDE seems (at least to a naive user like me) to be
deeply wedded to it. There are even direct mentions of artsd setup in
FWIW.... aRts is needed for KDE 3, but has been removed for KDE 4. It is
replaced by Phonon. From what I gather, Phonon is more of an API (like
PortAudio) than a sound server (like aRts). However, it is able to be
configured with different backends (libxine, gstreamer, NMM, and Helix are listed).
For more info:
http://multimedia.kde.org/arts-faq.php
http://phonon.kde.org/
HTH,
Gabriel
2:10 p.m.
On Sun, 14 Jun 2009, Gabriel M. Beddingfield wrote:
Okay, thanks for the info. By the way, is KDE 4 still a mess (as I keep
hearing), or should all the fear and loathing subside now?
(Still wondering about possible effects of global banning of esd...)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
Brent Busby wrote:
Could be. I'm still on Debian etch, so I don't have it yet whatever it
is. Question is though, is it really necessary? Or is it benign enough
that it can be safely allowed regardless?
PortAudio:
Isn't PortAudio an API... not a sound server? Arts
("artsd"):
I already have some doubts about eliminating this one, at least in any
system that hopes to have a KDE desktop available. Even if we don't need
it per se, KDE seems (at least to a naive user like me) to be deeply wedded
to it. There are even direct mentions of artsd setup in
FWIW.... aRts is needed for KDE 3, but has been removed for KDE 4. It is
replaced by Phonon. From what I gather, Phonon is more of an API (like
PortAudio) than a sound server (like aRts). However, it is able to be
configured with different backends (libxine, gstreamer, NMM, and Helix are
listed). 
3:50 p.m.
On Sunday 14 June 2009 18.10.51 Brent Busby wrote:
Okay, thanks for the info. By the way, is KDE 4 still
a mess (as I keep
hearing), or should all the fear and loathing subside now?
If someone says that now: don't listen to them, it's probably the old Desktop
War ghost running in someone's mind.
Many people (including me) are using KDE4 and it's very clean and user centric
(and thank God, it's still hacker friendly, users are still not protected
against them self as in some other environments/OSs) ;-) . However, I did not
go from KDE3 before 4.1 was out.
Look at this:
http://www.josander.net/images/kde4.png
If you look at the right side, I have my Desktop Icons in groups (DAW, System,
Guitar, Synths/Sampler etc) and the Desktop folder in a plasma widget (avoidin
loads of icons here and there. I do also normally hide my panel but shows it
now for the screenshot. Also, I use GTK, KDE, QT and Gnome apps when needed,
no problem. Why do some people still have problem using an app just because
it's a QT or KDE app? I don't get that.
Messy? No way!
Jostein
4:13 p.m.
Hiho,
On Sunday 14 June 2009 13:50:26 Jostein Chr. Andersen wrote:
On Sunday 14 June 2009 18.10.51 Brent Busby wrote:
What are you using for these groups?
I upgraded a while ago, but am not completely happy yet... I miss the single
command line widget to just launch programs from (the one that someone made is
still rather buggy, and doesn't work well in the panel). And I'm getting weird
interferences with OpenGL apps; I suspect there is some weird interaction
going on there between KDE4 using OpenGL and the app using it.
sincerely,
Marije
Okay, thanks for the info. By the way, is KDE 4
still a mess (as I keep
hearing), or should all the fear and loathing subside now?
If someone says that now: don't listen to them, it's probably the old
Desktop War ghost running in someone's mind.
Many people (including me) are using KDE4 and it's very clean and user
centric (and thank God, it's still hacker friendly, users are still not
protected against them self as in some other environments/OSs) ;-) .
However, I did not go from KDE3 before 4.1 was out.
Look at this:
http://www.josander.net/images/kde4.png
If you look at the right side, I have my Desktop Icons in groups (DAW,
System, Guitar, Synths/Sampler etc) and the Desktop folder in a plasma
widget (avoidin loads of icons here and there. I do also normally hide my
panel but shows it now for the screenshot. Also, I use GTK, KDE, QT and
Gnome apps when needed, no problem. Why do some people still have problem
using an app just because it's a QT or KDE app? I don't get that.
Messy? No way! 
15 Jun
15 Jun
1:53 a.m.
Many people (including me) are using KDE4 and it's
very clean and user centric
i found it overtly hostile to basic tasks, like finding a web browser in an app menu
plus it caused the boot-to-GUI proces to take 3 minutes
no problem. Why do some people still have problem
using an app just because
it's a QT or KDE app? I don't get that.
because, at least on Gentoo, it requires compiling all of KDE and QT, which can be a
multi-day affair (compare w/ 5 seconds for dwm, 10 mins for xorg, and 15 for webkit, a
'WebOS' system in a half hour)
then when you launch a KDElibs app, it launches 10 odd daemons, kdeserver, dcop, etcetc,
sucking 200 MB of ram
Messy? No way!
the hodgepodge of panels and default icons was certainly messy
2:05 a.m.
On Sun, 14 Jun 2009, carmen wrote:
All this KDE versus non-KDE is interesting, but I already know the
downsides of KDE itself. I don't run it all the time, but like having
it on my system as an available choice.
I was just wondering though whether v4 was quite ready, or whether I
should stick to KDE 3. I suppose there are a lot of opinions on that
though, since there's a lot of discussion on that already on the
Internet right now.
For me, it comes down to:
Do you think I should allow 'qt4' in $USE at this point, or should I
stick to 'qt3' only for now? Loaded question, I know...
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
Many people
(including me) are using KDE4 and it's very clean and user centric
i found it overtly hostile to basic tasks, like finding a web browser in an app menu
plus it caused the boot-to-GUI proces to take 3 minutes
no problem. Why do some people still have problem
using an app just because
it's a QT or KDE app? I don't get that.
because, at least on Gentoo, it requires compiling all of KDE and QT, which can be a
multi-day affair (compare w/ 5 seconds for dwm, 10 mins for xorg, and 15 for webkit, a
'WebOS' system in a half hour)
then when you launch a KDElibs app, it launches 10 odd daemons, kdeserver, dcop, etcetc,
sucking 200 MB of ram
Messy? No way!
the hodgepodge of panels and default icons was certainly messy
4:05 a.m.
On Monday 15 June 2009 05.52.23 carmen wrote:
20 seconds here! :-)
This is not a problem on *Ubuntus, Fedoras and other mainstream distros, it's
already compiled. I used LFS (manuell compilationa as oposite to Gentoo)
several years, and when I compiled apps like QT, I just did something else in
the meantime, like working, sleeping or whatever.
Many people
(including me) are using KDE4 and it's very clean and user
centric
i found it overtly hostile to basic tasks, like finding a web browser in an
app menu
plus it caused the boot-to-GUI proces to take 3 minutes no problem.
Why do some people still have problem using an app just
because it's a QT or KDE app? I don't get that.
because, at least on Gentoo, it requires compiling all of KDE and QT,
which can be a multi-day affair (compare w/ 5 seconds for dwm, 10 mins for
xorg, and 15 for webkit, a 'WebOS' system in a half hour)
then when you launch a KDElibs app, it launches 10 odd daemons, kdeserver,
dcop, etcetc, sucking 200 MB of ram
Perhaps you misunderstood me? I wrote apps (".. a QT or KDE app"), not
environment. :-) Gnome is neat and slick, I like it and many other people like
it, I just like KDE better.
Well, I can understand that people don't use a program because they don't like
it, or are using something that they think is better, but choose away an app
because of the tookit?. I don't like GTK and wxWidgets, but it's no way that I
stop using two of my favorite apps because their toolkits: Ardour (GTK)and
Audacity(wx). I even use wx on an Opensource project (SocratiMA) I'm working
on that will be finished by end of this year.
Jostein
Messy? No way!
the hodgepodge of panels and default icons was certainly messy 
6:19 a.m.
On Mon, 15 Jun 2009 01:52:23 pm carmen wrote:
Interesting
K->Applications->Internet->Web Browser (Firefox) does it here for me and seems
a pretty obvious location to me.... Also try K menu then type in "web" or
"fire" or "ope" on the keyboard... You can do this without the mouse
by using
"Alt + F2".
There is a web browser by default in the favourites menu... (the first thing
you see when you click on the K) if your favourite browser is not the default
you can right click on it's menu entry and select add to favourites. You can
also remove items you don't use from the favourites menu by right clicking on
them.
Should you prefer a KDE3 style menu you can get that too by right clicking on
the K and selecting - Switch to classic style.
What would be a less "hostile" approach?
--
Your wise men don't know how it feels
To be thick as a brick.
-- Jethro Tull, "Thick As A Brick"
Many people
(including me) are using KDE4 and it's very clean and user
centric
i found it overtly hostile to basic tasks, like finding a web browser in an
app menu 
10:39 a.m.
GNOME has never managed to impress me one bit. It looks and acts like a 90's
environment. To me, the only reason for its mass adoption was Qt's licensing
(and history would agree). I see no technical or aesthetical benefit. It
took me only a couple of hours to create a small in-house cross-platform
accounting utility with Qt and Python - with the help of designer & py2exe.
It looks and works great on Linux _and_ Windows.
On the other hand, Enlightenment is a fine piece of art. Couple it with KDE,
disable composite extensions, and you have the perfect blend of beauty and
usability. With KDE, you get what you expect, you get what you want, and you
get what you see, unlike GNOME.
For audio though, one should look at Juce instead.
12:58 p.m.
Ray Rashif wrote:
GNOME has never managed to impress me one bit. It
looks and acts like a
90's environment.
I'm not sure what a 90's environment looks and and acts like, could you
elaborate a bit?
Funny thing is, this must mean I just stepped down to an 80's
environment (openbox under arch), although I did this very deliberately
and it feels like a step *up* :-)
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
1:25 p.m.
On Mon, Jun 15, 2009 at 6:58 PM, Atte Andre Jensen<atte.jensen(a)gmail.com> wrote:
Ray Rashif wrote:
Fluxbox and Gentoo here.
And i remember Cream's "White Room" from the FIRST time it came out.......
Dark side of the Moon anyone?
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
GNOME has never managed to impress me one bit. It
looks and acts like a
90's environment.
I'm not sure what a 90's environment looks and and acts like, could you
elaborate a bit?
Funny thing is, this must mean I just stepped down to an 80's
environment (openbox under arch), although I did this very deliberately
and it feels like a step *up* :-)
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
3:08 p.m.
alex stone wrote:
Fluxbox and Gentoo here.
And i remember Cream's "White Room" from the FIRST time it came out.......
Dark side of the Moon anyone?
second generation listener, but sure :)
us, and them,
and after all we're only ordinary men
how did waters know about the gnome/kde quarrel in 73? ;)
reminds me of that great cartoon i saw years ago: a man and a boy hide
behind a trashcan in some huge metropolis, boy says, "why do we have to
hide from the police, daddy?", father responds, "because they use vi,
son. we use emacs."
6:12 p.m.
2009/6/15 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>
alex stone wrote:
http://spamatica.se/music/spamatica/default/spamatica_-_kde_vs_gnome-1.8.ogg
;-)
A quarrel I will never get tired of
Fluxbox and Gentoo here.
And i remember Cream's "White Room" from the FIRST time it came
out.......
Dark side of the Moon anyone?
second generation listener, but sure :)
us, and them,
and after all we're only ordinary men
how did waters know about the gnome/kde quarrel in 73? ;) reminds me of that great cartoon i saw years ago: a
man and a boy hide
behind a trashcan in some huge metropolis, boy says, "why do we have to
hide from the police, daddy?", father responds, "because they use vi,
son. we use emacs."
Ahh, freedom
/Robert
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
16 Jun
16 Jun
5:27 a.m.
On Monday 15 June 2009 22.12.40 Robert Jonsson wrote:
http://spamatica.se/music/spamatica/default/spamatica_-_kde_vs_gnome-1.8.og
g
;-)A quarrel I will never get tired of
Hey, this is really cool, haven't heard this before! :-)
J.
10:58 a.m.
2009/6/16 Jostein Chr. Andersen <jostein(a)vait.se>
On Monday 15 June 2009 22.12.40 Robert Jonsson wrote:
http://spamatica.se/music/spamatica/default/spamatica_-_kde_vs_gnome-1.8.og
>g
> ;-)A quarrel I will never get tired
of
Hey, this is really cool, haven't heard this before! :-)
Thank you, it's an old tune that never seems to get too old... :)
Regards,
Robert
19 Jun
19 Jun
10:58 a.m.
Am 15.06.2009 um 19:08 schrieb Jörn Nettingsmeier <nettings(a)folkwang-hochschule.d
e>:
how on earth do you people know what i am listening to during
lunchbreak right now? LAU magic.
alex stone wrote:
> Fluxbox and Gentoo here.
> And i remember Cream's "White
Room" from the FIRST time it came
> out.......
ha! that's the first song i've ever played in a band. great memories...
Dark side of the Moon anyone?
second generation listener, but sure :)
us, and them,
and after all we're only ordinary men
how did waters know about the gnome/kde quarrel in 73? ;)
reminds me of that great cartoon i saw years ago: a man and a boy hide
behind a trashcan in some huge metropolis, boy says, "why do we have
to
hide from the police, daddy?", father responds, "because they use vi,
son. we use emacs."
"look, mommy! there's an airplane up in the sky!"
- Burkhard
15 Jun
15 Jun
5:08 p.m.
Atte Andre Jensen <atte.jensen(a)gmail.com>
I'm not sure what a 90's environment looks and and acts like, could you
elaborate a bit?
Funny thing is, this must mean I just stepped down to an 80's
environment (openbox under arch), although I did this very deliberately
and it feels like a step *up* :-)
That should've been obvious from the statement itself. Since GNOME looks and
acts like a 90's environment, a 90's environment looks and acts like GNOME.
OK, no more suspense. Basically, OS 9.
WMs like Awesome, Xmonad, *box are not in the equation. In fact, they _are_
a step up because they serve their purpose of being (lightweight or not)
window managers. I'm an Xmonad user as well.
14 Jun
14 Jun
10:43 p.m.
On Sun, June 14, 2009 11:10 am, Brent Busby wrote:
Okay, thanks for the info. By the way, is KDE 4 still
a mess (as I keep
hearing), or should all the fear and loathing subside now?
No, it is not a mess. My well meaning brother installed a laptop with
Kubuntu and KDE4 for my dear old mom to use. (argh....) Still, it's
worked out OK. The only trouble I've had is configuring the wireless
applet to work with WPA.
KDE 4 is definately worth a look. However, I'm not switching my family's
desktops yet. ("Daddy!! Why did you have to go and change
everything?!?!")
(Still wondering about possible effects of global
banning of esd...)
:-)
--
G a b r i e l M B e d d i n g f i e l d
15 Jun
15 Jun
12:19 a.m.
Phonon is to KDE what PulseAudio is to GNOME. What's more, Phonon beats the
crap outta PulseAudio for being simplistic.
I have been a KDE and pro-audio user for about 4 years, and KDE 4 is truly a
blessing. Phonon with the Xine backend has proved to be the ultimate
environment. I start JACK and two instances of TiMidity++ (one ALSA out, one
JACK out) on bootup (as user in realtime with proper privilleges), which is
very simply taken care of by Phonon (System Settings > Multimedia > Select
JACK as first device for all). It is intelligent to fall to the next device
in case of a failure, and then return once again if JACK is running anew.
I have no other server interfering with the flow/chain, and with the ALSA
JACK plug-in I can even play games like Urban Terror. However, this is only
an abuse test - don't use JACK as a generic sound server! (definitely never
meant to be one, though it appears to be able to handle whatever you throw
at it)
14 Jun
14 Jun
2:27 p.m.
On Sun, Jun 14, 2009 at 8:15 AM, Brent Busby<brent(a)keycorner.org> wrote:
Now that I've gotten a pretty clear picture of the
concensus about
PulseAudio, I wondered about some of the other (new and old) sound
facilities in Linux, and specifically wondered if being on a system like
Gentoo where one can turn off build-time support for these things is a
good idea. So...
PortAudio:
From what I can see, this doesn't do much. It seems to provide an API
of sorts that unifies Linux sound with sound on other operating systems.
(For example, FreeBSD supports PortAudio, even though its an OSS-based
system.) Then again, I thought Alsa's OSS emulation provided a
'/dev/dsp' that did that already. Anyway...
Is this bad? Has anyone had nearly the nightmares with
PortAudio presence in a DAW system that's described from users of newer
systems with PulseAudio? I don't want to incriminate it just because
its name is similar. (Though I do find myself calling PortAudio
"PulseAudio" by accident a lot. They really could have found a better
name for that...)
Gentoo has a USE flag to disable PortAudio, but I hesitate to do
so if most of the apps these days are taking its presence as a given. I
don't want to diverge from what's perceived as "normal" upstream more
than necessary to achieve good results.
Esound ("esd"):
This is truly 90's technology that won't die, and we all know that.
The question is, how much of an assumption is it in the apps (and in the
Gnome desktop) to the extent that if it weren't there, there would be
problems? Is it safe on a Gentoo system to globally ban build support
for ESD? Sure, Alsa has its own mixer, but will the apps just
transparently use it if ESD isn't around? This is really the gist of
all my questions here: We know there are daemons we don't like. But
which ones are safe to actually kill, and which ones do we still sadly
depend on for something or other?
Arts ("artsd"):
I already have some doubts about eliminating this one, at least in any
system that hopes to have a KDE desktop available. Even if we don't
need it per se, KDE seems (at least to a naive user like me) to be
deeply wedded to it. There are even direct mentions of artsd setup in
some of the audio setup panels of the KDE Control Panel. Does banning
Artsd support equal losing all desktop audio support in KDE? It looks
like it might...experiences?
I guess what I'm thinking is that it'd be nice to do a build in which
everything but Alsa and Jack is banished to hell, but I'm wondering if
that will leave some programs at a loss to find a mixer at all, and thus
without sound. Ideally, all sound apps, regardless of what target
they're expecting, ought to be able to transparently find the Alsa
mixer, and multiplex with other apps to share access with it
simultaneously, also without special setup.
Does that work?
(I'd even put up with artsd if I had to, since KDE seems to assume it,
and since it doesn't seem to cause major problems...)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
I have no problems running Gnome with all the old sound flags turned
off. Note that I don't have any trouble running Gnome even with
-gnome, -kde & -python although I turn those on for a few packages in
portage.use.
I don't run KDE so I cannot speak to that at all.
Hope this helps,
Mark
mark@lightning ~/Desktop $ cat /etc/make.conf
# These settings were set by the catalyst build script that
automatically built this stage
CFLAGS="-march=k8 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"
FEATURES="parallel-fetch distclean ccache"
USE="cdda cddb realmedia quicktime dri radeon mmx mmxext sse sse2
3dnow 3dnowext -gnome -kde -esd -arts ladspa nptl nptlonly audiofile
gimp ppds usb alsa cdr dvd dvdr dvdread jack fluidsynth tcltk sndfile
v4l v4l2 mysql flac -samba i8x0 mythtv -lirc mjpeg xvid xine cjk
unicode vorbis ogg truetype java -eds -dts a52 odbci -cups -odbc
-python"
ACCEPT_KEYWORDS="amd64"
ALSA_CARDS="hdsp9652 hdsp"
VIDEO_CARDS="radeon vesa fbdev"
INPUT_DEVICES="evdev"
LINGUAS="en"
PORTAGE_NICENESS=19
EMERGE_DEFAULT_OPTS="--with-bdeps y"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ "
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
source /usr/local/portage/layman/make.conf
mark@lightning ~/Desktop $
4:39 p.m.
On Sun, Jun 14, 2009 at 11:15 AM, Brent Busby<brent(a)keycorner.org> wrote:
Now that I've gotten a pretty clear picture of the
concensus about
PulseAudio, I wondered about some of the other (new and old) sound
facilities in Linux, and specifically wondered if being on a system like
Gentoo where one can turn off build-time support for these things is a
good idea. So...
PortAudio:
PortAudio is just a portable API. there is no server, no backend
anything. It doesn't provide shared hardware access. It is unrelated
to everything else in your list.
Ideally, all sound apps, regardless of what target
they're expecting, ought to be able to transparently find the Alsa
mixer, and multiplex with other apps to share access with it
simultaneously, also without special setup.
There is no "ALSA mixer" for multiplexing apps unless you mean dmix
and or a "share" plugin. Both of these "work" for some definition of
the term, but both have also been tested and found wanting as a
general solution to the problem of shared h/w access.
5:55 p.m.
On Sun, Jun 14, 2009 at 02:38:56PM -0400, Paul Davis wrote:
There is no "ALSA mixer" for multiplexing
apps unless you mean dmix
and or a "share" plugin. Both of these "work" for some definition of
the term, but both have also been tested and found wanting as a
general solution to the problem of shared h/w access.
'For some value of the term' is quite correct, and one may wonder
why that is the case.
AFAICS, Alsa has shot itself in the foot by trying to provide
too much. Generally the 'driver' part works well, but all the
user space things stacked on it have a tendency to fail to
meet expectations, and IMHO should be replaced by some other
solution.
There should be *one* and only *one* entity setting the HW
parameters - period, sample rate, format, etc. *One* way to
wait for and access sample data which provides no extra
buffering, no conversions of any sort, and which requires
the client to be real-time. Basically the way Jack uses Alsa.
Providing software mixing on top of that would be relatively
simple - Jack does it all the time. And there Alsa should
end.
All the rest - format and sample rate conversion, extra
buffering allowing a client to be lazy and non-RT, other
ways to access samples - should be provided by a library
that apps link with, instead of trying to create 'devices'
that try to provide the zillions of possible combinations
and generally fail to do that.
If such a library had been created by the ALSA devs instead
of all the 'plugins' we would not have needed any of the
large collection of desktop servers we have now.
Just my 2 eurocents, of course.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
15 Jun
15 Jun
12:27 a.m.
On Sun, Jun 14, 2009 at 3:51 PM, Fons Adriaensen<fons(a)kokkinizita.net> wrote:
AFAICS, Alsa has shot itself in the foot by trying to
provide
too much. Generally the 'driver' part works well, but all the
user space things stacked on it have a tendency to fail to
meet expectations, and IMHO should be replaced by some other
solution.
There should be *one* and only *one* entity setting the HW
parameters - period, sample rate, format, etc. *One* way to
wait for and access sample data which provides no extra
buffering, no conversions of any sort, and which requires
the client to be real-time. Basically the way Jack uses Alsa.
Providing software mixing on top of that would be relatively
simple - Jack does it all the time. And there Alsa should
end.
All the rest - format and sample rate conversion, extra
buffering allowing a client to be lazy and non-RT, other
ways to access samples - should be provided by a library
that apps link with, instead of trying to create 'devices'
that try to provide the zillions of possible combinations
and generally fail to do that.
lets be fair to ALSA. this design is a result of pressure from actual
app developers. i think you sometimes forget that the world of audio
programming extends way, way outside people who want the kinds of
things that we tend to want. take a look at phonon (from KDE) - this
is a living, breathing definition of the kind of thing that
non-pro-audio, non-music-creation, non-sound-installation audio app
developers imagine they want. but ALSA tries to give this same general
idea to them in a rather interesting way: your code doesn't vary when
you use a device that can support your data streams natively (in
hardware) versus when you use one that requires some extra conversion.
open "hw:0" and then do FOO. alternatively, open "plughw:0" and then
do FOO, regardless of the capabilities of the underlying hardware. FOO
remains constant. No "if (hw->can_support (sample_rate)) { ... }"
conditionals etc etc.
this was no small accomplishment, even if for the subset of the audio
programming world that we tend to inhabit, its largely irrelevant. the
idea that you can write a single chunk of audio io code, and
regardless of the capabilities of the underlying hardware, it will
just work - this was really quite a large goal for ALSA. maybe it
would have been preferable to have started with something more like
gstreamer - this behaves in a way similar to the broad goals that you
are describing, even if its API has some baroque complications. but i
think the vision/gaze/focus was just on a different model - open the
real hw, use it as-is, or open up a virtual device and have things
"just work".
where things maybe went wrong was the idea of defining a lot of
different *kinds* of virtual devices via a config file, including ones
that did multi-app multiplexing, device sharing, even i/o to
non-hardware devices like the ALSA JACK plugin.
now compare the situation with CoreAudio (i know, i know: i sound like
a broken record). there is only 1 sample format when interacting with
an audio interface. but there are lots of appallingly designed APIs
for stream conversion before you hit the "hardware". moreover the
device you open will do multiplexing to the real hardware *AND* sample
rate conversion automagically. yet - this whole system can be
reasonably easily made to reroute any applications audio via a
user-space system like JACK without the app even knowing anything
about it. there is also an "aggregate device" system similar to ALSA's
"multi" plugin, and which works even worse (or at least, in a way that
puts some absurd requirements on an app developer - oops, all playback
channels from your device just vanished). the similarities and
differences with ALSA are remarkable.
If such a library had been created by the ALSA devs
instead
of all the 'plugins' we would not have needed any of the
large collection of desktop servers we have now.
i don't think this is accurate. esd and artsd predated ALSA. when we
started work on JACK, nobody really knew how it should work (in terms
of implementation or API or general design). what does seem sad in
retrospect was that when we started JACK we did so in a context that
was deliberately "non ALSA". this had had costs - JACK lives outside
ALSA - but also benefits - JACK runs on all 3 major contemporary
operating systems. the goals for JACK at that time seemed like
something that was outside the scope of what ALSA was attempting to
accomplish, but in hindsight, it all seems very much part of the same
goal(s).
3:14 a.m.
On Sun, 2009-06-14 at 22:27 -0400, Paul Davis wrote:
On Sun, Jun 14, 2009 at 3:51 PM, Fons
Adriaensen<fons(a)kokkinizita.net> wrote:
I understand that it was a huge leap at the time but......
I don't know nothing, and most probably things have changed a LOT since
then, but when I actually tried to write an alsa backend for snd a long
long time ago I failed[*]. You could either use the hw interface,
connect to the sound card directly and then deal with _everything_ in
your program, or you could use the plug interface and get the advantage
of automatic conversions, etc, etc, but then you would be _completely_
isolated from the hardware, you could _not_, for example, find out how
many _real_ channels the hardware behind the plug interface had (to
actually record from them!). It was impossible, you could not even find
which "hw" was behind "plughw" (everything could be potentially
reconfigured though confi files so your guess could be wrong, or at
least I convinced myself of that at the time). If you used plughw, ALSA
would happily tell you that it could record from something like 4
billion channels (or some other equally ridiculous number). This was not
"logically" wrong (and I remember arguing about this), but it was worse
than useless.
For me there was a disconnect between the needs of a programmer writing
a real app and what ALSA provided.
[*] to to take advantage of what alsalib supposedly could do :-)
AFAICS, Alsa has shot itself in the foot by
trying to provide
too much. Generally the 'driver' part works well, but all the
user space things stacked on it have a tendency to fail to
meet expectations, and IMHO should be replaced by some other
solution.
There should be *one* and only *one* entity setting the HW
parameters - period, sample rate, format, etc. *One* way to
wait for and access sample data which provides no extra
buffering, no conversions of any sort, and which requires
the client to be real-time. Basically the way Jack uses Alsa.
Providing software mixing on top of that would be relatively
simple - Jack does it all the time. And there Alsa should
end.
All the rest - format and sample rate conversion, extra
buffering allowing a client to be lazy and non-RT, other
ways to access samples - should be provided by a library
that apps link with, instead of trying to create 'devices'
that try to provide the zillions of possible combinations
and generally fail to do that.
lets be fair to ALSA. this design is a result of pressure from actual
app developers. i think you sometimes forget that the world of audio
programming extends way, way outside people who want the kinds of
things that we tend to want. take a look at phonon (from KDE) - this
is a living, breathing definition of the kind of thing that
non-pro-audio, non-music-creation, non-sound-installation audio app
developers imagine they want. but ALSA tries to give this same general
idea to them in a rather interesting way: your code doesn't vary when
you use a device that can support your data streams natively (in
hardware) versus when you use one that requires some extra conversion.
open "hw:0" and then do FOO. alternatively, open "plughw:0" and then
do FOO, regardless of the capabilities of the underlying hardware. FOO
remains constant. No "if (hw->can_support (sample_rate)) { ... }"
conditionals etc etc. this was no small accomplishment, even if for the
subset of the audio
programming world that we tend to inhabit, its largely irrelevant. the
idea that you can write a single chunk of audio io code, and
regardless of the capabilities of the underlying hardware, it will
just work - this was really quite a large goal for ALSA. maybe it
would have been preferable to have started with something more like
gstreamer - this behaves in a way similar to the broad goals that you
are describing, even if its API has some baroque complications. but i
think the vision/gaze/focus was just on a different model - open the
real hw, use it as-is, or open up a virtual device and have things
"just work".
In a real program that could record that was, I believe, impossible. Now
if you are talking about a simple program that would, say, play a
soundfile, then yes, of course it worked.
where things maybe went wrong was the idea of defining
a lot of
different *kinds* of virtual devices via a config file, including ones
that did multi-app multiplexing, device sharing, even i/o to
non-hardware devices like the ALSA JACK plugin.
Oh yeah. I never could really find out or understand how to deal with
that. Maybe I did not try hard enough. Right now thinking about it I am
reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
was not that bad :-)
-- Fernando
now compare the situation with CoreAudio (i know, i
know: i sound like
a broken record). there is only 1 sample format when interacting with
an audio interface. but there are lots of appallingly designed APIs
for stream conversion before you hit the "hardware". moreover the
device you open will do multiplexing to the real hardware *AND* sample
rate conversion automagically. yet - this whole system can be
reasonably easily made to reroute any applications audio via a
user-space system like JACK without the app even knowing anything
about it. there is also an "aggregate device" system similar to ALSA's
"multi" plugin, and which works even worse (or at least, in a way that
puts some absurd requirements on an app developer - oops, all playback
channels from your device just vanished). the similarities and
differences with ALSA are remarkable.
If such a library had been created by the ALSA
devs instead
of all the 'plugins' we would not have needed any of the
large collection of desktop servers we have now.
i don't think this is accurate. esd and artsd predated ALSA. when we
started work on JACK, nobody really knew how it should work (in terms
of implementation or API or general design). what does seem sad in
retrospect was that when we started JACK we did so in a context that
was deliberately "non ALSA". this had had costs - JACK lives outside
ALSA - but also benefits - JACK runs on all 3 major contemporary
operating systems. the goals for JACK at that time seemed like
something that was outside the scope of what ALSA was attempting to
accomplish, but in hindsight, it all seems very much part of the same
goal(s).
10:09 a.m.
On Mon, Jun 15, 2009 at 1:14 AM, Fernando
Lopez-Lezcano<nando(a)ccrma.stanford.edu> wrote:
Oh yeah. I never could really find out or understand how to deal with
that. Maybe I did not try hard enough. Right now thinking about it I am
reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
was not that bad :-)
*NOTHING* could ever be that bad!
even the syntax of asoundrc is a stunning example of everything one
could ever wish for in a configuration system when compared to
sendmail rewriting rules. i guess the difference was that back in the
day, it seemed normal to have to learn stuff like that, whereas now
... kids these days!
10:50 a.m.
Den Monday 15 June 2009 14.09.21 skrev Paul Davis:
On Mon, Jun 15, 2009 at 1:14 AM, Fernando
Lopez-Lezcano<nando(a)ccrma.stanford.edu> wrote:
Much have been said about sendmail. Most of it true :-). The Unix-haters
handbook (1994) dedicated a chapter about trouble with sendmail, and this
questionable title. "Sendmail: The Vietnam of Berkeley Unix".
Here's an excerpt from the book:
"Sendmail was built while the Internet mail handling systems were in flux.
As a result, it had to be programmable so that it could handle any possible
changes in the standards. Delve into the mysteries of sendmail’s unread-
able sendmail.cf files and you’ll discover ways of rewiring sendmail’s
insides so that “@#$@$^%<<<@#) at @$%#^!” is a valid e-mail address.
That was great in 1985. In 1994, the Internet mail standards have been
decided upon and such flexibility is no longer needed. Nevertheless, all of
sendmail’s rope is still there, ready to make a hangman’s knot, should any-
one have a sudden urge."
/bengan
Oh yeah. I never could really find out or
understand how to deal with
that. Maybe I did not try hard enough. Right now thinking about it I am
reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
was not that bad :-)
*NOTHING* could ever be that bad!
even the syntax of asoundrc is a stunning example of everything one
could ever wish for in a configuration system when compared to
sendmail rewriting rules. i guess the difference was that back in the
day, it seemed normal to have to learn stuff like that, whereas now
... kids these days! 
11:42 a.m.
On Mon, 15 Jun 2009 05:14:46 +0000
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> wrote:
Oh yeah. I never could really find out or understand
how to deal with
that. Maybe I did not try hard enough. Right now thinking about it I am
reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
was not that bad :-)
*whimpering and resisting the urge to hide under the bed*
I remember having to modify a rule in sendmail.cf back in the days before
the web, before m4 macros, when 10Base5 was how we were wiring boxes together.
Do you have any idea how long it took me to figure out that tabs != spaces?
It took a sick, sick mind to come up with the obfuscated hell that is
sendmail.cf. I thought I'd gotten over the trauma, but the shakes have
returned, so perhaps I'm not really past it.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
12:01 p.m.
Fernando Lopez-Lezcano wrote:
> Oh yeah. I never could really find out or
understand how to deal with
> that. Maybe I did not try hard enough. Right now thinking about it I am
> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> was not that bad :-)
>
Is there any such thing as a fond memory of sendmail.cf ?
Best,
dp
3:16 p.m.
Dave Phillips wrote:
Fernando Lopez-Lezcano wrote:
oh yes, i have a recollection about it that borders on the erotic.
it happened on the day when i switched to postfix and went
$~> rm sendmail.cf
> Oh yeah. I never could really find out or
understand how to deal with
> that. Maybe I did not try hard enough. Right now thinking about it I am
> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> was not that bad :-)
>
Is there any such thing as a fond memory of sendmail.cf ?
18 Jun
18 Jun
3:28 p.m.
On Monday 15 June 2009 13:16:20 Jörn Nettingsmeier wrote:
Dave Phillips wrote:
It seems to me that to have braved sendmail and telling these anecdotes is
very much like veteran war stories...
sincerely,
marije
Fernando Lopez-Lezcano wrote:
oh yes, i have a recollection about it that borders on the erotic.
it happened on the day when i switched to postfix and went
$~> rm sendmail.cf > Oh yeah. I never could really find out or
understand how to deal with
> that. Maybe I did not try hard enough. Right now thinking about it I am
> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> was not that bad :-)
Is there any such thing as a fond memory of sendmail.cf ? 
15 Jun
15 Jun
3:23 p.m.
On Monday 15 June 2009 16:01:44 Dave Phillips wrote:
Fernando Lopez-Lezcano wrote:
Maybe the day you deleted it because it was obsoleted?
Arnold, using KDE4 and liking it:P
> Oh yeah. I never could really find out or
understand how to deal with
> that. Maybe I did not try hard enough. Right now thinking about it I am
> reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
> was not that bad :-)
Is there any such thing as a fond memory of sendmail.cf ?
3:43 p.m.
I think I'm going to go with KDE 4, just because it's the future, like
it or not. Short of setting up a standalone machine that never gets
updated, no one can stay on KDE 3 forever, so I'm plunging forward.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
18 Jun
18 Jun
10:44 a.m.
On Mon, 2009-06-15 at 12:43 -0500, Brent Busby wrote:
I think I'm going to go with KDE 4, just because
it's the future, like
it or not. Short of setting up a standalone machine that never gets
updated, no one can stay on KDE 3 forever, so I'm plunging forward.
This is a rather blanket statement.. Linux is each to their own "freedom
of choice"... If someone gets the functionality they need from a wm and
it happens to be manually configured (like the old days)..
for those of us that have been using linux for "pro" audio purposes for
a while we have learnt that an non-obtrusive wm tends to allow for lower
latencies (less polling happening)...
but as I said each to their own..
23 Jun
23 Jun
5:43 p.m.
On Thu, 18 Jun 2009, allan wrote:
On Mon, 2009-06-15 at 12:43 -0500, Brent Busby wrote:
It's true, very true that in Linux, nobody's making your update your
software. But my studio machine is not so dedicated that it's not also
on the Internet. I like getting security updates...and eventually,
there comes a point where a KDE 3 desktop is just not patchable anymore.
Since I posted that, I decided to go with KDE 3 afterall, and did
install it, but I still know I can't stay forever...not if I want to
keep on getting security support.
On the bright side, it's not as obnoxious as some company changing their
file formats every release version just to keep you upgrading because
they arbitrarily want to keep taking your money.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
I think I'm going to go with KDE 4, just
because it's the future, like
it or not. Short of setting up a standalone machine that never gets
updated, no one can stay on KDE 3 forever, so I'm plunging forward.
This is a rather blanket statement.. Linux is each to their own "freedom
of choice"... If someone gets the functionality they need from a wm and
it happens to be manually configured (like the old days)..
for those of us that have been using linux for "pro" audio purposes for
a while we have learnt that an non-obtrusive wm tends to allow for lower
latencies (less polling happening)...
but as I said each to their own..
15 Jun
15 Jun
7:43 p.m.
On Mon, Jun 15, 2009 at 05:14:46AM +0000, Fernando Lopez-Lezcano wrote:
First thing I do when installig Fedora is remove sendmail
and install postfix - for the sole reason that I'm capable
of configuring postfix in less than 48 hours :-)
Seriously now, talking about ALSA let's just consider resampling.
Assume your hardware is running at 48 kHz and you want to use
44.1 kHz.
Typical audio hardware will interrupt whenever it has N
samples available for reading and writing, where in many
cases N will be a power of 2.
Now if you resample that you have basically two choices:
1. Keep the 'period time' generated by the HW, i.e. provide
an interface that will trigger its client at the same rate.
The consequence is that you don't have a fixed number of
samples (in this example, if the HW period is 1024, you
would have eiter 940 or 941 samples in a period). This
would be unacceptable to some clients, e.g. Jack.
2. Try to create an interface that will offer a fixed 2^n
period size. This requires extra buffering, in other words
increased latency. And the timing of such periods will be
irregular. In some cases a HW capture buffer will not be
sufficent to generate a resampled buffer, you have to wait
an extra period and you better have some samples buffered if
the client wants them. In a similar way, a single playback
buffer could complete two HW buffers, forcing you to store
one of them. If you want the period times to be more or less
regular, this again requires more latency.
A client would quite legitimately expect the two resampled
streams (capture and playback) to have the same period timing,
as they would have for direct HW access. But in ALSA dmix and
share are independent plugins, so anything goes. And even if
they were coupled, synchronising the two streams could again
imply more latency (it's possible but not simple to avoid
this).
The conclusion is that resampling at the sound card API, if
this is in any way 'period based' breaks things, at least in
the sense that it introduces more latency than the resampling
operation (which implies filtering and hence delay) does on its
own.
And there is no good reason for ever doing that.
Applications like soft synths should be capable of generating
their output at the sample rate imposed by the hardware. The
*only* cases were resampling is really needed is when dealing
with *stored* data (either being read or written). But in that
caes there will be buffering between the storage and the RT
audio code, and *that* is the right place to apply resampling,
it costs nothing (in terms of timing) if done there.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
where things
maybe went wrong was the idea of defining a lot of
different *kinds* of virtual devices via a config file, including ones
that did multi-app multiplexing, device sharing, even i/o to
non-hardware devices like the ALSA JACK plugin.
Oh yeah. I never could really find out or understand how to deal with
that. Maybe I did not try hard enough. Right now thinking about it I am
reminded of unraveling rewriting rules in sendmail.cf (oh well, no, it
was not that bad :-)
16 Jun
16 Jun
2:08 a.m.
On Mon, Jun 15, 2009 at 5:40 PM, Fons Adriaensen<fons(a)kokkinizita.net> wrote:
Typical audio hardware will interrupt whenever it has
N
samples available for reading and writing, where in many
cases N will be a power of 2.
neither USB nor firewire devices work this way, and are instead based
on clocks that are unrelated to audio sample rate. i believe that you
know this :)
The conclusion is that resampling at the sound card
API, if
this is in any way 'period based' breaks things,
this is part (a big part) of the reason why CoreAudio's HAL API is not
based on hardware interrupts at all. it adds a small amount of latency
(and i continue to suspect that apple is playing conservative with
their "safety buffer"). the system is elegant (its basically a DLL
with a small offset built in), allows resampling and many other cool
things. PulseAudio is also using a similar model layered "above" ALSA.
And there is no good reason for ever doing that.
Applications like soft synths should be capable of generating
their output at the sample rate imposed by the hardware. The
*only* cases were resampling is really needed is when dealing
with *stored* data (either being read or written). But in that
caes there will be buffering between the storage and the RT
audio code, and *that* is the right place to apply resampling,
it costs nothing (in terms of timing) if done there.
infrastructure like gstreamer has done this for years. problem is (a)
the architecture is baroque (b) their resampler is poor quality and an
unbelievable CPU hog.
15 Jun
15 Jun
4:05 a.m.
On Sun, Jun 14, 2009 at 11:51 PM, Fons Adriaensen<fons(a)kokkinizita.net> wrote:
On Sun, Jun 14, 2009 at 02:38:56PM -0400, Paul Davis
wrote:
in the kernel, and jack do the rest sounds appealing. I think the alsa
team continue to do a great job, but maybe their workload could be
even easier to manage if they just did H/W devices/modules, and let
Jack "manage" as it seems to be specifically designed to do.
I use a lot of midi (big orchestral templates), and have had quite a
few adventures with timing, ports, etc..using alsa. I respectfully
suggest that in this area too, alsa only occupies itself in the
kernel, and jackmidi assumes the sample accurate responsibility for
any midi requirements.
Ergo, i respectfully ask devs for the few programmes that still use
alsa midi, to consider a push towards replacing it with, or adding
jackmidi, and then we'll all be singing from the same orchestral
score, to sample accurate level.
Then alsa can do what it does best, at kernel/hw device level, and
jack can take the blame/credit for the rest....
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org,
There is no "ALSA mixer" for
multiplexing apps unless you mean dmix
and or a "share" plugin. Both of these "work" for some definition of
the term, but both have also been tested and found wanting as a
general solution to the problem of shared h/w access.
'For some value of the term' is quite correct, and one may wonder
why that is the case.
AFAICS, Alsa has shot itself in the foot by trying to provide
too much. Generally the 'driver' part works well, but all the
user space things stacked on it have a tendency to fail to
meet expectations, and IMHO should be replaced by some other
solution.
There should be *one* and only *one* entity setting the HW
parameters - period, sample rate, format, etc. *One* way to
wait for and access sample data which provides no extra
buffering, no conversions of any sort, and which requires
the client to be real-time. Basically the way Jack uses Alsa.
Providing software mixing on top of that would be relatively
simple - Jack does it all the time. And there Alsa should
end.
All the rest - format and sample rate conversion, extra
buffering allowing a client to be lazy and non-RT, other
ways to access samples - should be provided by a library
that apps link with, instead of trying to create 'devices'
that try to provide the zillions of possible combinations
and generally fail to do that.
If such a library had been created by the ALSA devs instead
of all the 'plugins' we would not have needed any of the
large collection of desktop servers we have now.
Just my 2 eurocents, of course.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
From just one "power" user's perspective, having alsa only do its bit
5634
days inactive
5643
days old
linux-audio-user@lists.linuxaudio.org
37 comments
21 participants
participants (21)
-
alex stone -
allan -
Arnold Krille -
Atte Andre Jensen -
Bengt Gördén -
Brent Busby -
Burkhard Wölfel -
carmen -
Danni Coy -
Dave Phillips -
Fernando Lopez-Lezcano -
Fons Adriaensen -
Gabriel M. Beddingfield -
Joe Hartley -
Jostein Chr. Andersen -
Jörn Nettingsmeier -
Mark Knecht -
nescivi -
Paul Davis -
Ray Rashif -
Robert Jonsson