After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 405020 - [alsa] probing the device-name doesn't seem to work correctly
[alsa] probing the device-name doesn't seem to work correctly
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.10
Other Linux
: Normal normal
: 0.10.12
Assigned To: Tim-Philipp Müller
GStreamer Maintainers
: 405024 (view as bug list)
Depends on:
Blocks: 339897
 
 
Reported: 2007-02-06 16:14 UTC by Snark
Modified: 2007-02-09 13:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test program to print the list of available devices (1.41 KB, text/x-csrc)
2007-02-06 16:16 UTC, Snark
  Details
Solution to the problem (629 bytes, patch)
2007-02-06 17:46 UTC, Snark
needs-work Details | Review
Solution to the problem (1.07 KB, patch)
2007-02-07 14:02 UTC, Snark
none Details | Review

Description Snark 2007-02-06 16:14:43 UTC
Here is what my system has :
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: SI7012 [SiS SI7012], device 0: Intel ICH [SiS SI7012]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Modem [SiS SI7013 Modem], device 0: Intel ICH - Modem [SiS SI7013 Modem - Modem]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
and here is what my test program sees :
$ ./audio
alsasrc device=hw:0,0 name=dsnoop:0
alsasrc device=hw:0,1 name=dsnoop:0
alsasrc device=hw:1,0 name=dsnoop:0
(I'll attach the source of my test program to this bug)
Comment 1 Snark 2007-02-06 16:16:15 UTC
Created attachment 82024 [details]
Test program to print the list of available devices

I'll work on it if I find the time.
Comment 2 Tim-Philipp Müller 2007-02-06 16:45:38 UTC
*** Bug 405024 has been marked as a duplicate of this bug. ***
Comment 3 Snark 2007-02-06 17:46:30 UTC
Created attachment 82031 [details] [review]
Solution to the problem

This makes my test program spit :
$ ./audio
alsasrc device=hw:0,0 name=SiS SI7012
alsasrc device=hw:0,1 name=SiS SI7012
alsasrc device=hw:1,0 name=SiS SI7012
which is the best alsa is able to make as a user-friendly string (sic).
Comment 4 Snark 2007-02-06 19:58:12 UTC
Warning : my patch isn't good enough... apparently card is always set to 0.

I could see it when I plugged my webcam in and it showed the same name again : it should definitely look worse.
Comment 5 Snark 2007-02-07 08:40:27 UTC
I can snd_ctl_open "hw:0", but not "hw:0,1"... and of course, I only have the later available as the device in alsasrc.

The following piece of code :
  if (snd_ctl_open (&ctl, "hw:0", 0))
    printf ("Open failed!\n");
  else {
    
    printf ("Open succeeded!\n");
    snd_ctl_card_info_malloc (&info);
    snd_card_get_name (snd_ctl_card_info_get_card (info), &name);
    printf ("Name : %s\n", name);
    free (name);
    snd_ctl_card_info_free (info);
    snd_ctl_close (ctl);
  }

Prints :
Open succeeded!
Name : SiS SI7012

Which is what we want...

I really like how crystal clear the ALSA api is...
Comment 6 Snark 2007-02-07 14:02:00 UTC
Created attachment 82085 [details] [review]
Solution to the problem

This one gives better results.
Comment 7 Tim-Philipp Müller 2007-02-08 15:43:04 UTC
Solved this a bit differently:

  2007-02-08  Tim-Philipp Müller  <tim at centricular dot net>

        Based on patch by: Julien Puydt <julien.puydt at laposte net>

        * ext/alsa/gstalsa.c: (gst_alsa_find_device_name_no_handle),
        (gst_alsa_find_device_name):
        * ext/alsa/gstalsa.h:
        * ext/alsa/gstalsasink.c: (gst_alsasink_get_property):
        * ext/alsa/gstalsasrc.c: (gst_alsasrc_get_property):
          Improve device-name detection a bit, especially in the case where
          the device is not actually open (#405020, #405024). Move common code
          into gstalsa.c instead of duplicating it.

This works better for me at least, let me know if that's not the case for you.

Comment 8 Snark 2007-02-08 19:11:45 UTC
Hmmm... sorry, but your patch doesn't seem to work that well:
$ ./audio
alsasrc device=hw:0,0 name=dsnoop:0
alsasrc device=hw:0,1 name=dsnoop:0
alsasrc device=hw:1,0 name=dsnoop:0

What did it give on your setup?
Comment 9 Tim-Philipp Müller 2007-02-08 19:46:41 UTC
It gave me exactly the same as the very last [foo] bit in the output of aplay -l / arecord -l. What's the output of 

 $ GST_DEBUG=*alsa*:5 ./audio

in your case?
Comment 10 Snark 2007-02-09 07:15:47 UTC
Here's the end of the log :
0:00:00.525863000  3435 0x804d890 LOG                   alsa gstalsadeviceprobe. c:174:gst_alsa_device_property_probe_get_values:<test> Found device: hw:0,0
0:00:00.526017000  3435 0x804d890 LOG                   alsa gstalsadeviceprobe. c:174:gst_alsa_device_property_probe_get_values:<test> Found device: hw:0,1
0:00:00.526066000  3435 0x804d890 LOG                   alsa gstalsadeviceprobe. c:174:gst_alsa_device_property_probe_get_values:<test> Found device: hw:1,0
0:00:00.526142000  3435 0x804d890 LOG                   alsa gstalsa.c:457:gst_a lsa_find_device_name:<test> Trying to get device name from open handle
0:00:00.526192000  3435 0x804d890 LOG                   alsa gstalsa.c:481:gst_a lsa_find_device_name:<test> Device name for device 'hw:0,0': dsnoop:0
alsasrc device=hw:0,0 name=dsnoop:0
0:00:00.526337000  3435 0x804d890 LOG                   alsa gstalsa.c:457:gst_a lsa_find_device_name:<test> Trying to get device name from open handle
0:00:00.526383000  3435 0x804d890 LOG                   alsa gstalsa.c:481:gst_a lsa_find_device_name:<test> Device name for device 'hw:0,1': dsnoop:0
alsasrc device=hw:0,1 name=dsnoop:0
0:00:00.526464000  3435 0x804d890 LOG                   alsa gstalsa.c:457:gst_a lsa_find_device_name:<test> Trying to get device name from open handle
0:00:00.526509000  3435 0x804d890 LOG                   alsa gstalsa.c:481:gst_a lsa_find_device_name:<test> Device name for device 'hw:1,0': dsnoop:0
alsasrc device=hw:1,0 name=dsnoop:0
Comment 11 Snark 2007-02-09 08:07:42 UTC
Eh... if I comment out the line :
gst_element_set_state (elt, GST_STATE_PAUSED);
in audio.c, then I get good results again ; and those results come from :
GST_LOG_OBJECT (obj, "name from pcminfo: %s", GST_STR_NULL (ret));
which means that contrary to what I thought, snd_pcm_info_get_name can get good results.

Let me try to summarize what is currently done to get a name :
- if opened handle, then
  - try snd_pcm_info_get_name directly (doesn't work here) ;
  - if it didn't work, fallback to non-open case
- if non-opened handle, then
  - try to snd_ctl_open, then
    - if it fails, NULL
    - if it works, then
      - snd_pcm_info_get_name indirectly (works here)
      - if it fails, snd_card_get_name (works here)
      - it this fails too, NULL

Would it fly to :
- try to snd_ctl_open, then
  - if it fails, NULL
  - if it works, then
    - snd_pcm_info_get_name indirectly
    - if it fails, snd_card_get_name
    - if it fails too, NULL
?
Comment 12 Tim-Philipp Müller 2007-02-09 10:04:38 UTC
Okay, let's try it the other way around then (use open handle last):

 2007-02-09  Tim-Philipp Müller  <tim at centricular dot net>

        * ext/alsa/gstalsa.c: (gst_alsa_find_device_name):
          Try to get devic-name from device string first, and from handle only
          as fallback (seems to yield better results and is more robust
          against buggy probing code on the application side).

Does this work better for you?
Comment 13 Snark 2007-02-09 13:37:09 UTC
Yes!

Perfect!

Wonderful!

Thanks!