path: root/meta/recipes-extended
diff options
authorTanu Kaskinen <tanuk@iki.fi>2019-02-20 17:11:45 +0200
committerTanu Kaskinen <tanuk@iki.fi>2019-02-21 22:07:27 +0200
commit52ec539cbf4ec7511f1259fef31e0c13244b0836 (patch)
tree95f88e94b272147d4b1a15c31537e2264bf2c437 /meta/recipes-extended
parent106c5467f93806485716f5a964d60929fcf777f1 (diff)
alsa-utils: 1.1.6 -> 1.1.8tanuk/updates
Changelogs: http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7 http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 There's a new program, axfer, which is a reimplementation of aplay (and arecord). The purpose of the rewrite is to have code that is easier to maintain. For now both implementations exist, and I decided to put both in the aplay package. The new 89-alsa-ucm.rules udev file initializes the mixer settings for certain hardware. It's needed for making the hardware usable at boot, in case there's no higher level software (such as PulseAudio) managing the mixer settings. Shipping hardware specific configuration in alsa-utils seems wrong, but I don't know what else to do. I added it to the alsaucm package, because it's kind of tied to the alsaucm utility (the udev rules execute the alsaucm program, and the build system installs the rules file only when alsaucm is enabled). Ideally the UCM configuration in alsa-lib would define the default UCM verb for each hardware, then the udev rules file could just enable the default verb, and there would be no hardware specific configuration in alsa-utils. But that requires upstream development effort. SRC_URI was changed to a more reliable source (at least currently the ftp server is flaky). Signed-off-by: Tanu Kaskinen <tanuk@iki.fi>
Diffstat (limited to 'meta/recipes-extended')
0 files changed, 0 insertions, 0 deletions