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 478292 - Audio device cannot be specified in OS X
Audio device cannot be specified in OS X
Status: RESOLVED WONTFIX
Product: esound
Classification: Deprecated
Component: general
unspecified
Other Mac OS
: Normal normal
: ---
Assigned To: Esound Maintainers
Esound Maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2007-09-19 09:32 UTC by Ojas Parekh
Modified: 2012-02-28 20:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to audio_coreaudio.c to allow device specification (7.63 KB, patch)
2007-09-19 09:33 UTC, Ojas Parekh
none Details | Review

Description Ojas Parekh 2007-09-19 09:32:54 UTC
I've included a patch to audio_coreaudio.c that allows coreaudio device specification on the command line, e.g.:

[dbook: /tmp]$ esd -d "Built-in Input"
- using device Built-in Input
using device Soundflower (2ch) for output:
        with sample rate 44100.000000, 2 channels and 32-bit sample
using device Built-in Input for input:
        with sample rate 44100.000000, 2 channels and 32-bit sample

A complication is that a specified device may not have both input and output capabilities, in which case the driver resorts to the default input or output device.  In the above example, "Built-in Input" does not have any output channels, so the driver selected "Soundflower (2ch)," which is the default output device on my system, for output.

Specifiying a coreaudio device through a configuration file or environment variable is still problematic since device names may have spaces and spaces are treated as separators in parsing these.
Comment 1 Ojas Parekh 2007-09-19 09:33:59 UTC
Created attachment 95838 [details] [review]
patch to audio_coreaudio.c to allow device specification
Comment 2 Daniel Macks 2007-09-19 18:57:16 UTC
How about separate command-line flags and parameters for input vs output? That way one can choose non-default for both, but also have those choices each (perhaps) only be able to do one direction. Passing with spaces is just the price one has to pay for having devices with spaced in their names...command-line users should already be comfortable with standard command-line techniques (though a help message explaining how that got displayed if user goofs (detected as parameters without flags( would be good).
Comment 3 André Klapper 2012-02-28 20:32:45 UTC
"esound" has not seen code changes for more than three years according to http://git.gnome.org/browse/esound/log/ , and it will not see further active development anymore according to its developers.

Closing this report as WONTFIX - Please feel free to reopen this bug report in
the future if anyone takes the responsibility for active development again.