Hello guys,
there is a new version of s-c-s in rawhide (2.0.0). It has some new features like new GUI, proc&HAL detection, driver reloading and card ordering.
I'll be happy for any feedback and/or BZ entries.
Martin
Martin Stransky (stransky@redhat.com) said:
Hello guys,
there is a new version of s-c-s in rawhide (2.0.0). It has some new features like new GUI, proc&HAL detection, driver reloading and card ordering.
I'll be happy for any feedback and/or BZ entries.
So...
The sound test failed when I had rhythmbox running.
Aside from that, the usage model seems very strange.
1) I'm supposed to pick a PCM device and know what the difference is between:
Intel 82801DB-ICH4 Intel 82801DB-ICH4 - MIC ADC Intel 82801DB-ICH4 - MIC2 ADC Intel 82801DB-ICH4 - ADC2 Intel 82801DB-ICH4 - IEC958
intuitively? (Moreover, I'm asked to do this in two different places.)
2) I can choose to have no default audio card. Not sure that makes sense.
3) How is the user supposed to know whether to use kudzu, /proc, or HAL detection? Why are they even *given* a choice???
I'm failing to see what sort of usage case this is solving. Surely this should all just work?
(I note we have a completely different Sound preference anyway, which is somewhat simpler.)
Bill
Bill Nottingham wrote:
Martin Stransky (stransky@redhat.com) said:
Hello guys,
there is a new version of s-c-s in rawhide (2.0.0). It has some new features like new GUI, proc&HAL detection, driver reloading and card ordering.
I'll be happy for any feedback and/or BZ entries.
So...
The sound test failed when I had rhythmbox running.
Do you think it's a bug?
Aside from that, the usage model seems very strange.
I'm supposed to pick a PCM device and know what the difference is between:
Intel 82801DB-ICH4 Intel 82801DB-ICH4 - MIC ADC Intel 82801DB-ICH4 - MIC2 ADC Intel 82801DB-ICH4 - ADC2 Intel 82801DB-ICH4 - IEC958
intuitively? (Moreover, I'm asked to do this in two different places.)
These names depend on driver writer, if you don't know just use the default. Optionally I can move it to some "advanced" settings.
- How is the user supposed to know whether to use kudzu, /proc, or HAL detection? Why are they even *given* a choice???
I'm failing to see what sort of usage case this is solving. Surely this should all just work?
It's because:
kudzu detects only internal cards (kudzu doesn't detect USB cards well), but it works even if you don't have loaded drivers. So you can reload drivers for your card if something bad happens, you have ISA card and so on.
Proc detects all cards fine, but it isn't "preferred" and works only when drivers are succesfully loaded.
HAL detects only cards with correct /sys entries (so it doesn't detect SB 7.1 on my box) so drivers must be loaded. But it detects USB devices fine.
So, when HAL detects all devices fine, I'll remove proc&kudzu.
- I can choose to have no default audio card. Not sure that makes sense.
It's related to detection, if your card isn't detected any way (kudzu/HAL) but is there, I'm not going to screw up your config file and I'll leave it as it is.
(I note we have a completely different Sound preference anyway, which is somewhat simpler.)
I've never heard anything about "Sound preference", so if there is something like that can I read it somewhere?
Martin
On Mon, Jul 03, 2006 at 10:58:49AM +0200, Martin Stransky wrote:
- I'm supposed to pick a PCM device and know what the difference is
between: Intel 82801DB-ICH4 Intel 82801DB-ICH4 - MIC ADC Intel 82801DB-ICH4 - MIC2 ADC Intel 82801DB-ICH4 - ADC2 Intel 82801DB-ICH4 - IEC958 intuitively? (Moreover, I'm asked to do this in two different places.)
These names depend on driver writer, if you don't know just use the default. Optionally I can move it to some "advanced" settings.
Is there a case where a normal person would want the non-default?
- How is the user supposed to know whether to use kudzu, /proc, or HAL
detection? Why are they even *given* a choice??? I'm failing to see what sort of usage case this is solving. Surely this should all just work?
It's because: kudzu detects only internal cards (kudzu doesn't detect USB cards well),
[...]
Proc detects all cards fine, but it isn't "preferred" and works only when drivers are succesfully loaded.
[...]
HAL detects only cards with correct /sys entries (so it doesn't detect
[...]
So, when HAL detects all devices fine, I'll remove proc&kudzu.
Why not, in the meantime, do them all? Or do HAL first, and if that fails, kudzu, and if that fails, proc? (Possibly with a "look for more" button?)
Matthew Miller wrote:
On Mon, Jul 03, 2006 at 10:58:49AM +0200, Martin Stransky wrote:
- I'm supposed to pick a PCM device and know what the difference is
between: Intel 82801DB-ICH4 Intel 82801DB-ICH4 - MIC ADC Intel 82801DB-ICH4 - MIC2 ADC Intel 82801DB-ICH4 - ADC2 Intel 82801DB-ICH4 - IEC958 intuitively? (Moreover, I'm asked to do this in two different places.)
These names depend on driver writer, if you don't know just use the default. Optionally I can move it to some "advanced" settings.
Is there a case where a normal person would want the non-default?
- How is the user supposed to know whether to use kudzu, /proc, or HAL
detection? Why are they even *given* a choice??? I'm failing to see what sort of usage case this is solving. Surely this should all just work?
It's because: kudzu detects only internal cards (kudzu doesn't detect USB cards well),
[...]
Proc detects all cards fine, but it isn't "preferred" and works only when drivers are succesfully loaded.
[...]
HAL detects only cards with correct /sys entries (so it doesn't detect
[...]
So, when HAL detects all devices fine, I'll remove proc&kudzu.
Why not, in the meantime, do them all? Or do HAL first, and if that fails, kudzu, and if that fails, proc? (Possibly with a "look for more" button?)
this would be a good idea something like no soundcard found should I try an other method to detect? yes -no
dragoran (dragoran@feuerpokemon.de) said:
this would be a good idea something like no soundcard found should I try an other method to detect? yes -no
... But why would you even get into this situation?
Any drivers should automatically loaded, which means that ALSA probing via HAL should work. If there isn't a driver for your card, there's really nothing the tool's going to be able to do for you.
Bill
Bill Nottingham wrote:
dragoran (dragoran@feuerpokemon.de) said:
this would be a good idea something like no soundcard found should I try an other method to detect? yes -no
... But why would you even get into this situation?
Any drivers should automatically loaded, which means that ALSA probing via HAL should work. If there isn't a driver for your card, there's really nothing the tool's going to be able to do for you.
Bill
I have already posted it TV cards and modules like saa7134-alsa (don't know if any of this methods can detect it thought), it does not gets autoloaded and kudzu does nothing about it ? should I fill this as abug? if yes against what? kernel? kudzu?
dragoran (dragoran@feuerpokemon.de) said:
Any drivers should automatically loaded, which means that ALSA probing via HAL should work. If there isn't a driver for your card, there's really nothing the tool's going to be able to do for you.
I have already posted it TV cards and modules like saa7134-alsa (don't know if any of this methods can detect it thought), it does not gets autoloaded and kudzu does nothing about it ? should I fill this as abug? if yes against what? kernel? kudzu?
kernel/udev. kudzu does not load modules in current releases.
Bill
Bill Nottingham wrote:
dragoran (dragoran@feuerpokemon.de) said:
Any drivers should automatically loaded, which means that ALSA probing via HAL should work. If there isn't a driver for your card, there's really nothing the tool's going to be able to do for you.
I have already posted it TV cards and modules like saa7134-alsa (don't know if any of this methods can detect it thought), it does not gets autoloaded and kudzu does nothing about it ? should I fill this as abug? if yes against what? kernel? kudzu?
kernel/udev. kudzu does not load modules in current releases.
Bill
bug filled against udev: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197807 but this seems to be a udev and kernel issue
Le Lun 3 juillet 2006 15:48, Matthew Miller a écrit :
On Mon, Jul 03, 2006 at 10:58:49AM +0200, Martin Stransky wrote:
- I'm supposed to pick a PCM device and know what the difference is
between: Intel 82801DB-ICH4 Intel 82801DB-ICH4 - MIC ADC Intel 82801DB-ICH4 - MIC2 ADC Intel 82801DB-ICH4 - ADC2 Intel 82801DB-ICH4 - IEC958 intuitively? (Moreover, I'm asked to do this in two different
places.) These names depend on driver writer, if you don't know just use the default. Optionally I can move it to some "advanced" settings.
Is there a case where a normal person would want the non-default?
Any user which needs non-stereo output (5.1 DVD sound...) will need to wade through the non-defaut settings (with the cryptic alsa naming). In those cases the default may not even be plugged anywhere.
Right now this concerns a growing minority of normal persons, in a few years I expect it to be pretty much everyone. So this is a real problem.
Regards,
On Mon, Jul 03, 2006 at 04:01:44PM +0200, Nicolas Mailhot wrote:
Any user which needs non-stereo output (5.1 DVD sound...) will need to wade through the non-defaut settings (with the cryptic alsa naming). In those cases the default may not even be plugged anywhere.
Hmmm. In that case, maybe something more directly explanatory than just "advanced" -- and maybe pointers to the documentation appropriate for that card? At least until something more magical can happen...
Le lundi 03 juillet 2006 à 13:12 -0400, Matthew Miller a écrit :
On Mon, Jul 03, 2006 at 04:01:44PM +0200, Nicolas Mailhot wrote:
Any user which needs non-stereo output (5.1 DVD sound...) will need to wade through the non-defaut settings (with the cryptic alsa naming). In those cases the default may not even be plugged anywhere.
Hmmm. In that case, maybe something more directly explanatory than just "advanced" -- and maybe pointers to the documentation appropriate for that card? At least until something more magical can happen...
It's not just "that card". Pretty much every alsa driver I've seen exports I/Os as cryptic labels, and no one ever bothered to map then to human-readable labels. Hell sometimes when you ask on alsa lists alsa people defer to whoever wrote the driver because they're not able to deduce function from naming themselves (that's what you get from revelling in being close to the hardware and forgetting the user view)
This is a disaster waiting to happen. XFree86 modelines and other black magic all over again.
Regards,
On Mon, Jul 03, 2006 at 07:45:06PM +0200, Nicolas Mailhot wrote:
Hmmm. In that case, maybe something more directly explanatory than just "advanced" -- and maybe pointers to the documentation appropriate for that card? At least until something more magical can happen...
It's not just "that card". Pretty much every alsa driver I've seen exports I/Os as cryptic labels, and no one ever bothered to map then to
I'm sorry, I was unclear. I meant "whichever card is detected".
This is a disaster waiting to happen. XFree86 modelines and other black magic all over again.
Sounds like it.
[...] It's because:
kudzu detects only internal cards (kudzu doesn't detect USB cards well), but it works even if you don't have loaded drivers. So you can reload drivers for your card if something bad happens, you have ISA card and so on.
Proc detects all cards fine, but it isn't "preferred" and works only when drivers are succesfully loaded.
HAL detects only cards with correct /sys entries (so it doesn't detect SB 7.1 on my box) so drivers must be loaded. But it detects USB devices fine.
So, when HAL detects all devices fine, I'll remove proc&kudzu. [..]
what about TV cards that are able to record sound? in FC5 I can't see it and I have to load saa7134-alsa via modprobe to get it loaded (and added it to rc.local)
Martin Stransky (stransky@redhat.com) said:
The sound test failed when I had rhythmbox running.
Do you think it's a bug?
Depends. Opening up a gst pipleine to play the test sound may be overkill.
- I'm supposed to pick a PCM device and know what the difference is
between:
Intel 82801DB-ICH4 Intel 82801DB-ICH4 - MIC ADC Intel 82801DB-ICH4 - MIC2 ADC Intel 82801DB-ICH4 - ADC2 Intel 82801DB-ICH4 - IEC958
intuitively? (Moreover, I'm asked to do this in two different places.)
These names depend on driver writer, if you don't know just use the default. Optionally I can move it to some "advanced" settings.
What situations would someone logically wan to suggest a non-default? Using SPDIF? Something else?
- How is the user supposed to know whether to use kudzu, /proc, or HAL
detection? Why are they even *given* a choice???
I'm failing to see what sort of usage case this is solving. Surely this should all just work?
It's because:
kudzu detects only internal cards (kudzu doesn't detect USB cards well), but it works even if you don't have loaded drivers. So you can reload drivers for your card if something bad happens, you have ISA card and so on.
But this isn't something the user can fix, so why are we handling it here?
I guess my concern is, why are we giving the user a 'test if it works -> ok, it didn't -> punt' algorithm? Generally, they would get the same result if they started up their sound app and noticed it didn't work - what specific cases is this tool able to fix for them?
(I note we have a completely different Sound preference anyway, which is somewhat simpler.)
I've never heard anything about "Sound preference", so if there is something like that can I read it somewhere?
System->Prefereces->Sound under GNOME. KDE may have something else entirely.
Bill
Bill Nottingham (notting@redhat.com) said:
I've never heard anything about "Sound preference", so if there is something like that can I read it somewhere?
System->Prefereces->Sound under GNOME. KDE may have something else entirely.
So, looking at it some more, we've got at the moment:
1) system-config-soundcard - sets the default ALSA device for all users, by writing a system-specific config file 2) gnome-sound-properties - sets the default ALSA devices for GNOME apps using GStreamer, by changing GConf keys that apps read. Per-user. Allows you to set different devices for different types of apps. 3) KDE Control Center->Sound & Multimedia - sets the default output for arts to ALSA/OSS/esd/none 4) I'm sure KDE4 and Phonon will do something Entirely Different
Have we architected/designed how these will all fit together? Right now you can change things and test sounds in 3 different places, all of which could yield different results.
Bill
I guess my concern is, why are we giving the user a 'test if it works -> ok, it didn't -> punt' algorithm? Generally, they would get the same result if they started up their sound app and noticed it didn't work - what specific cases is this tool able to fix for them?
I removed these options and compacted all detection methods to one, it's in version 2.0.0-2 (in rawhide now).
Martin
On Fri, 2006-06-30 at 21:37 +0100, Richard Hughes wrote:
On Fri, 2006-06-30 at 16:43 +0200, Martin Stransky wrote:
features like new GUI, proc&HAL detection, driver reloading and card
Are there ever audio cards that a new HAL does not detect?
That's the point :) Old s-c-soundcard had problems detecting some stuff (like usb audio devices) and didn't really do hotplug very well. HAL lets us do this quite easily.
Dan
On Fri, 2006-06-30 at 16:43 +0200, Martin Stransky wrote:
there is a new version of s-c-s in rawhide (2.0.0). It has some new features like new GUI, proc&HAL detection, driver reloading and card ordering.
I'll be happy for any feedback and/or BZ entries.
Is this due to be in tomorrow's rawhide? As I don't see it in today's, or at least my mirror's as of 5pm CST today.
Martin Stransky ਨੇ ਲਿਖਿਆ:
Hello guys,
there is a new version of s-c-s in rawhide (2.0.0). It has some new features like new GUI, proc&HAL detection, driver reloading and card ordering.
I'll be happy for any feedback and/or BZ entries.
Martin
1) stop button does not stop Sound, music is going one, even message box appear to showing that "Did you hear sample sound?" 2) if you click on some other window, Message box hide behind main window, it like to be always on top of main window
thanks
-
A S Alam -
Bill Nottingham -
Dan Williams -
dragoran -
Martin Stransky -
Matthew Miller -
Mike Chambers -
Nicolas Mailhot -
Richard Hughes