aplay change to use 16-bit samples by default is not backwards compatible and is not documented

[nwoeanhinnogaehr]

The change introduced in 0c5948e breaks a lot of scripts and other programs I have which invoke aplay and expect the default sample format to be U8. While I think it's somewhat reasonable to make this change given that U8 is a rather low quality sample format, it's worth acknowledging that aplay has had this behavior for a very long time and many people probably don't expect it to change.

Given that the commit log seems to only talk about the case of arecord, I wonder if we could reach a compromise and keep the format as U8 for aplay and switch it for arecord, since users are unlikely to complain about poor sound quality when playing raw audio (surely they would take the time to get the sample format set up correctly before attempting to play raw audio).

Also, the man page has not been updated to reflect this change and still says that U8 is the default.

[pavhofman]

IMO a script which does not explicitly specify sample format and assumes a tool default value is buggy and should be fixed.

I would prefer if aplay and arecord used the same default values (be they U8 or S16_LE)

[nwoeanhinnogaehr]

Relying on default values is pretty essential to prevent every invocation from being absurdly verbose. For example you wouldn't run gcc foo.c and expect it to optimize with -O3 by default, or worse to pass -nostdlib by default. The default sample format is listed in the man page and has been unchanged for at least as long as this repo has existed (since 1998).

Perhaps it makes sense to change the default for recording wav files for the reasons outlined in the commit log, but I don't see why raw audio playback/recording should be affected. The commit in question is specifically talking about recording wav files. Yet it also changes the default for playing and recording raw audio (and voc and au files), with seemingly no consideration about those cases.

Also, if you're going to change the default sample format to 16 bit, why not change the rate from 8000Hz to 44100Hz? Surely users won't be happy with the quality of 8000Hz recordings.

[perexg]

For the second though, I take your arguments and trying to resolve the original problem with a warning in fc7500c . It seems like a good compromise.