On Tue, Oct 24, 2023 at 11:11:01PM +0600, Maria Morisot wrote: > > Forgive me if I'm dense, but I'm a better artist than I am a > programmer. I'm trying to follow you though. I understand why you > cannot seek in a pipe, but I do not understand why that affects > playback of a MS Wav file through a pipe.
There are two reasons: First, the .wav file may have many headers, in any order, and one data chunk. aucat has to parse certain headers (ex. to extract the data format and its size) and skip others (unused meta data). Currently, it uses lseek(2) to move the file pointer from one header to another and to move to the data location to start reading. This is how .wav files need to be handled, and as lseek(2) doesn't work on pipes aucat can't read .wav files from a pipe. However, on many simple .wav files the lseek(2) call is a no-op because there's no header to skip. Furthermore, to skip small headers and/or padding, read(2) could be used instead of lseek(2), which works on pipes. There's a second problem. The .wav file has a header that contains the data chunk size. Programs generating the .wav file, like faad, don't know the decoded data size in advance. So, they write the header with zeroed data size field, then write the data chunk, and finally lseek(2) to the header to fixup the data size field. This can't work with pipes because of the lseek(2) call and the files end up with an invalid header (zero data chunk size). Certain programs interpret zero as "until the end of the file" (mpv, ffmpeg) and manage to play such files, other as don't. The diff in the other mail addresses these two problems. > Aren't the headers kept in > the front, and my understanding is maybe you can grab enough bytes > to check if a header is present. I thought wav is just a raw sample > with a small header. I'd think a quick check for header wouldn't > upset playback for raw samples without one. Yes, this would be nice to have, to avoid using -h
