From: GitHub issues - opened <github@alsa-project.org>
To: alsa-devel@alsa-project.org
Subject: aplay does not use WAV/FLAC channel layout metadata, potentially causing incorrect multichannel playback unless --chmap is manually specified
Date: Thu, 9 Apr 2026 18:04:39 +0200 (CEST) [thread overview]
Message-ID: <18a4bbd47b537000-webhooks-bot@alsa-project.org> (raw)
In-Reply-To: <18a4bbd47abd3500-webhooks-bot@alsa-project.org>
alsa-project/alsa-utils issue #325 was opened from JonnyGators:
Summary
-------
When playing multichannel WAV or FLAC files, aplay ignores the
channel-layout metadata embedded in the file (WAV channel mask or FLAC
channel assignment). As a result, aplay always uses ALSA’s fallback
channel order (FL,FR,LFE,FC,RL,RR) unless the user manually specifies
--chmap.
This leads to incorrect channel routing (e.g., center/LFE swapped) even
when the file contains correct metadata describing the intended layout.
This appears to be a missing feature in aplay rather than an ALSA kernel
or alsa-lib issue, since ALSA’s design expects applications to interpret
metadata and call the chmap API accordingly.
Expected Behavior
-----------------
When playing a WAV or FLAC file that contains channel-layout metadata:
- aplay should read the channel mask / channel assignment
- aplay should translate that metadata into an ALSA channel map
- aplay should call snd_pcm_set_chmap() automatically
- playback should follow the file’s intended channel order without
requiring the user to manually specify --chmap
Actual Behavior
---------------
- aplay ignores WAV channel masks
- aplay ignores FLAC channel layouts
- aplay does not call snd_pcm_set_chmap()
- aplay uses ALSA’s fallback order (FL,FR,LFE,FC,RL,RR)
- multichannel playback is incorrect unless the user manually provides
--chmap=FL,FR,FC,LFE,RL,RR (or another appropriate map)
Why This Matters
----------------
Most modern multichannel formats (WAV, FLAC, Blu-ray PCM, Dolby, DTS,
ffmpeg, etc.) use the standard 5.1 order:
FL, FR, FC, LFE, RL, RR
Since aplay does not use metadata, it produces incorrect output on any
system where the ALSA fallback order differs from the file’s intended
order.
This behavior is surprising to users and inconsistent with ALSA’s own
expectation that applications should interpret metadata and set the
channel map explicitly.
Reproduction
------------
1. Use any 5.1 WAV or FLAC file with correct channel metadata.
2. Play with:
aplay -D hw:<device> file.wav
3. Observe incorrect channel routing (e.g., center and LFE swapped).
4. Play again with:
aplay -D hw:<device> --chmap=FL,FR,FC,LFE,RL,RR file.wav
5. Playback is now correct.
Request
-------
Please consider adding metadata parsing to aplay so that it:
- reads WAV channel masks
- reads FLAC channel layouts
- automatically sets the correct ALSA channel map
This would align aplay with ALSA’s documented expectation that
applications handle metadata and would greatly improve multichannel
playback correctness and usability.
Thank you for your time and consideration.
Issue URL : https://github.com/alsa-project/alsa-utils/issues/325
Repository URL: https://github.com/alsa-project/alsa-utils
parent reply other threads:[~2026-04-09 16:05 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <18a4bbd47abd3500-webhooks-bot@alsa-project.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18a4bbd47b537000-webhooks-bot@alsa-project.org \
--to=github@alsa-project.org \
--cc=alsa-devel@alsa-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox