12 Sep
2005
12 Sep
'05
12:59 p.m.
Greetings:
While I was working on the JACK article I was reminded how much I rely
on is Rui Capela's QJackCtl. I haven't touched JACK at the command-line
in a long while, thanks to QJC.
So I was thinking about the complexity of configuring ALSA and I
started wondering what I'd want to see in a more complete ALSA
configuration utility. I'm just rambling out loud here, so feel free to
add and comment:
1) A soundcard configuration utility that would install multiple
drivers in a single pass, order and reorder devices as you wish, and
provide useful help regarding module options. This utility would bundle
the edit jobs for modules.conf and supply the information from modinfo.
Optimally the modinfo output could be made selectable for instant
addition to the configuration. [Add relevant info here for doing the
same with the 2.6 modules system]
2) An auto-generated .asoundrc, based on the capabilities of your
cards and chipsets, and a facility for editing, saving and deleting that
file. The editor should provide examples and explanations for the
possible additions to .asoundrc.
3) Built-in utilities for IRQ ordering and other hardware optimizations.
4) A panel for a built-in mixer or facility to select a mixer, with
a store/restore interface to alsactl. Ideally the built-in mixer would
handle *any* soundcard supported by ALSA.
5) Start/stop/restart ALSA from the utility.
6) GUI for ALSA sequencer client connections.
7) Integrated loaders for soundfonts and other patches.
8) Display and control of ALSA's MIDI resources e.g. aseqnet, amidi,
Tooltips and other help should be available for every option and every
part of the configurator to make the setup easy and quick.
I realize that this utility could get rather big. Perhaps something
resembling xine's "level of mastery" could be added to divide the
utility into basic and advanced configuration panels ?
I think ALSA is a great system, but fully understanding it is
non-trivial, and its variety makes it difficult for a normal user to
"see" the whole system. QJC envelopes JACK and its possibilities in such
a way that it's often ready to rock at its defaults, and it makes it
easy to further configure the server if necessary. Certainly something
similar could happen for ALSA, yes ? A QAlsaCtl maybe ?
One problem: How to resist the temptation to refer to its acronym as
"quack"...
Best,
dp
12 Sep
12 Sep
3:45 p.m.
On Monday 12 September 2005 16:03, Dave Phillips wrote:
Greetings:
While I was working on the JACK article I was reminded how much I rely
on is Rui Capela's QJackCtl. I haven't touched JACK at the command-line
in a long while, thanks to QJC.
So I was thinking about the complexity of configuring ALSA and I
started wondering what I'd want to see in a more complete ALSA
configuration utility. I'm just rambling out loud here, so feel free to
add and comment:
[snipped]
Actually I can't think of anything to add right now, but I've saved this for
later reference. Alsaconf's interface is and has been awful for ages. I would
just put in a vote for building in such a way as to make a GTK2 interface
possible. Although a QT interface would be perfectly acceptable, in fact
anything has to better than ncurses. I started work on a PyGTK model of this
a while ago, but got distracted. I don't have the skills to implement the
hardware configuration stuff anyway, but it would be pretty easy to wrap
utilities that would be normally available from the command line.
Call the backend AlsaCtl - it's sort of obvious isn't it? and then you can
append the appropriate acronym for the front-end. The difficulty will be
avoiding a massive dependency chain doing it my way, that's if you want to
wash the dishes as well. ;) I shall doubtless leave the coding up to people
who know what they're doing, but it's something I have been pondering for a
while and I'd be happy to put some effort into making it happen.
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
4:14 p.m.
On Mon, 2005-09-12 at 18:45 +0100, tim hall wrote:
On Monday 12 September 2005 16:03, Dave Phillips
wrote:
Doesn't system-config-soundcard in Fedora already do all this?
Lee
Greetings:
While I was working on the JACK article I was reminded how much I rely
on is Rui Capela's QJackCtl. I haven't touched JACK at the command-line
in a long while, thanks to QJC.
So I was thinking about the complexity of configuring ALSA and I
started wondering what I'd want to see in a more complete ALSA
configuration utility. I'm just rambling out loud here, so feel free to
add and comment:
[snipped]
Actually I can't think of anything to add right now, but I've saved this for
later reference. Alsaconf's interface is and has been awful for ages. I would
just put in a vote for building in such a way as to make a GTK2 interface
possible. Although a QT interface would be perfectly acceptable, in fact
anything has to better than ncurses. I started work on a PyGTK model of this
a while ago, but got distracted. I don't have the skills to implement the
hardware configuration stuff anyway, but it would be pretty easy to wrap
utilities that would be normally available from the command line.
Call the backend AlsaCtl - it's sort of obvious isn't it? and then you can
append the appropriate acronym for the front-end. The difficulty will be
avoiding a massive dependency chain doing it my way, that's if you want to
wash the dishes as well. ;) I shall doubtless leave the coding up to people
who know what they're doing, but it's something I have been pondering for a
while and I'd be happy to put some effort into making it happen.
4:19 p.m.
Am Montag, 12. September 2005 17:03 schrieb Dave Phillips:
Greetings:
While I was working on the JACK article I was reminded how much I rely
on is Rui Capela's QJackCtl. I haven't touched JACK at the command-line
in a long while, thanks to QJC.
So I was thinking about the complexity of configuring ALSA and I
started wondering what I'd want to see in a more complete ALSA
configuration utility. I'm just rambling out loud here, so feel free to
add and comment:
1) A soundcard configuration utility that would install multiple
drivers in a single pass, order and reorder devices as you wish, and
provide useful help regarding module options. This utility would bundle
the edit jobs for modules.conf and supply the information from modinfo.
Optimally the modinfo output could be made selectable for instant
addition to the configuration. [Add relevant info here for doing the
same with the 2.6 modules system]
2) An auto-generated .asoundrc, based on the capabilities of your
cards and chipsets, and a facility for editing, saving and deleting that
file. The editor should provide examples and explanations for the
possible additions to .asoundrc.
3) Built-in utilities for IRQ ordering and other hardware
optimizations.
4) A panel for a built-in mixer or facility to select a mixer, with
a store/restore interface to alsactl. Ideally the built-in mixer would
handle *any* soundcard supported by ALSA.
5) Start/stop/restart ALSA from the utility.
6) GUI for ALSA sequencer client connections.
7) Integrated loaders for soundfonts and other patches.
8) Display and control of ALSA's MIDI resources e.g. aseqnet, amidi,
Tooltips and other help should be available for every option and every
part of the configurator to make the setup easy and quick.
I realize that this utility could get rather big. Perhaps something
resembling xine's "level of mastery" could be added to divide the
utility into basic and advanced configuration panels ?
I think ALSA is a great system, but fully understanding it is
non-trivial, and its variety makes it difficult for a normal user to
"see" the whole system. QJC envelopes JACK and its possibilities in such
a way that it's often ready to rock at its defaults, and it makes it
easy to further configure the server if necessary. Certainly something
similar could happen for ALSA, yes ? A QAlsaCtl maybe ?
One problem: How to resist the temptation to refer to its acronym as
"quack"...
Best,
dp
Do you know kasound?
I think it's a good start for point 2)
http://sourceforge.net/projects/kasound/
Best regards,
Martin
5:04 p.m.
On Mon, 2005-09-12 at 20:19 +0200, Martin Wohlleben wrote:
Am Montag, 12. September 2005 17:03 schrieb Dave
Phillips:
> 2) An auto-generated .asoundrc, based on the capabilities of your
> cards and chipsets, and a facility for editing, saving and deleting that
> file. The editor should provide examples and explanations for the
> possible additions to .asoundrc.
>
Do you know kasound?
I think it's a good start for point 2)
http://sourceforge.net/projects/kasound/
It's actually very, very rare for any user to need to modify
the .asoundrc. 99% of them seem to be under the mistaken impression
that they need to "create a correct .asoundrc for their soundcard" to
get the sound working, while the problem is usually some other bug (most
common is new hardware that ALSA doesn't fully support yet).
Shouldn't we "fix" point #2 by educating users instead?
Lee
5:43 p.m.
Shouldn't we "fix" point #2 by educating
users instead?
This will fail. Users do not want to get educated, they do not want to
read documentation, they want everything "simply working", without
paying for it with money or even time.
I really appreciate all effeorts to make free software more easy to use,
but OTOH: who uses free software has no right to demand anything,
except the case he or her has contributed to it.
Durus sed injustus.
Best regards
ce
11:24 p.m.
New subject: [linux-audio-user] Re: thoughts towards an ALSA configuration utility
I'm liking the sound of this effort btw.Things need to be easier to
make work and this is a nice way to do it. Is their currently an easy
(clicking) way to tell alsa you want your pci soundcard to be where
oss emulation connects to? All that kind of thing needs to be easier.
Can ksound generate asoundrc's for combining multiple cards? i.e like
the m-audio 1010 post that was on here recently. Less time screwing
round means more time making music, or coding which is always a good
thing ;-)
Loki
On 9/13/05, Christoph Eckert <ce(a)christeck.de> wrote:
Shouldn't we "fix" point #2 by
educating users instead?
This will fail. Users do not want to get educated, they do not want to
read documentation, they want everything "simply working", without
paying for it with money or even time.
I really appreciate all effeorts to make free software more easy to use,
but OTOH: who uses free software has no right to demand anything,
except the case he or her has contributed to it.
Durus sed injustus.
Best regards
ce
13 Sep
13 Sep
12:39 a.m.
On Mon, Sep 12, 2005 at 11:03:20AM -0400, Dave Phillips wrote:
1) A soundcard configuration utility that would
install multiple
drivers in a single pass, order and reorder devices as you wish
Is there a way to do this deterministicly? I can't even get Linux to
number my ALSA devices consistently under 2.6. It seems like a bit of
hotplug weirdness that goes away before I can debug it. I'd say it
crops up once a month or so, I unload the modules and reload them all
by hand, and it's fixed.
Once you throw USB devices into the mix, fixed device numbering goes
out the window and you can't predict what devices show up when. For
example, is there a way to tell the difference between two of the same
USD MIDI interface?
--
Ross Vandegrift
ross(a)lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
7:01 a.m.
Ross Vandegrift wrote:
Once you throw USB devices into the mix, fixed device
numbering goes
out the window and you can't predict what devices show up when. For
example, is there a way to tell the difference between two of the same
USD MIDI interface?
The driver has an option to differentiate between devices by their
product ID, but it won't work when those are the same model.
It's theoretically possible to look at the device path (shown in
/proc/asound/cards) which contains the hardware port number, but this
isn't supported yet.
Regards,
Clemens
7016
days inactive
7017
days old
linux-audio-user@lists.linuxaudio.org
8 comments
8 participants
participants (8)
-
Christoph Eckert -
Clemens Ladisch -
Dave Phillips -
Lee Revell -
Loki Davison -
Martin Wohlleben -
ross＠jose.lug.udel.edu -
tim hall