From: "Iain Sandoe" <iain@sandoe.co.uk>
To: Henry Worth <haworth@ncal.verio.com>, Takashi Oe <toe@unlserve.unl.edu>
Cc: linuxppc-dev@lists.linuxppc.org,
matthias pfisterer <matthias.pfisterer@gmx.de>
Subject: Re: CDDA playback on Pismo (and other newer models)
Date: Mon, 07 Aug 2000 10:03:23 +0100 [thread overview]
Message-ID: <200008070903.KAA25166@hyperion.valhalla.net> (raw)
On Mon, Aug 7, 2000, Henry Worth wrote:
> Takashi Oe wrote:
>>
>> On Sun, 6 Aug 2000, Henry Worth wrote:
>>
>> [...]
>> > This won't help in the esd case, it always sets the device to
>> > AFMT_S16_BE for 16 bit data on big endian systems (also doesn't deal
>> > with
>> > unsigned 16 bit data streams). Whereas the XMMS esd output plugin always
>> > passes the data through unchanged (little endian in the case of .wav).
>>
>> Does xmms' esd output plugin work with 16bit .wav at all on x86? Since
>> sox works just fine with 16bit .wav, and it doesn't do any byte swapping
>> either as far as I know (which is not much admittedly), I'm very much
>> inclined to think xmms+esd is plain broken with respect to 16bit wav.
>>
>> Takashi Oe
>
> The esd daemon sets the output to native endiness, so on an x86
> everyone is little endian and all should be well, but I haven't
> tried it.
so long as the last thing in the chain (i.e. the one that talks to /dev/dsp)
is prepared to:
*either* re-set the AFMT of /dev/dsp
(depending on the format of the stream presented to it)
*or* leave /dev/dsp AFMT at one setting
AND do the necessary conversions
everything will be OK.
Of course, there are other solutions - but these would depend on each app
"knowing" that the server only accepts input in format "XXX" which seems
broken to me... (although it has a certain simplicity - if there's a way of
telling the client apps that this is the case).
Iain.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next reply other threads:[~2000-08-07 9:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-07 9:03 Iain Sandoe [this message]
2000-08-07 19:18 ` CDDA playback on Pismo (and other newer models) Henry Worth
2000-08-08 5:02 ` Takashi Oe
2000-08-08 7:01 ` Henry Worth
-- strict thread matches above, loose matches on Subject: below --
2000-08-08 22:19 Henry Worth
2000-08-07 19:35 Iain Sandoe
2000-08-07 21:49 ` Henry Worth
2000-08-06 21:07 Henry Worth
2000-08-06 9:38 Iain Sandoe
2000-08-06 13:26 ` Takashi Oe
2000-08-06 18:36 ` Henry Worth
2000-08-07 1:25 ` Takashi Oe
2000-08-07 5:02 ` Henry Worth
2000-08-04 13:05 Iain Sandoe
2000-08-04 12:57 Benjamin Herrenschmidt
2000-08-04 9:16 Iain Sandoe
2000-08-04 20:40 ` Henry Worth
2000-08-04 21:03 ` Benjamin Herrenschmidt
2000-08-06 8:09 ` Henry Worth
2000-08-04 5:18 Henry Worth
2000-08-04 9:50 ` Michel Dänzer
2000-08-04 15:56 ` Nelson Abramson
2000-08-04 19:45 ` Henry Worth
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=200008070903.KAA25166@hyperion.valhalla.net \
--to=iain@sandoe.co.uk \
--cc=haworth@ncal.verio.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=matthias.pfisterer@gmx.de \
--cc=toe@unlserve.unl.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.