Re: CDDA playback on Pismo (and other newer models)

Re: CDDA playback on Pismo (and other newer models)

[Iain Sandoe]

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/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

On Mon, 7 Aug 2000, Iain Sandoe wrote:

> On  Mon, Aug 7, 2000,  Henry Worth  wrote:
> >
> > 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.

In the case of the esd daemon it does the ioctls to set the format
to signed native endiness, and they even do some error checking.

>
> 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.
>

It looks like esd is going for simplicity. Since they are mixing
digital sound streams to integrate sound sources on the desktop,
they ultimately need to get all the incoming data streams into native
endiness to do the mixing. I assume they just chose to put the
burden on the clients (I'll be charitable and not assume LE blindness
and that the setting to native endiness was a quick hack when the
endiness issue was brought to their attention). They would also
need common sample rates, but I haven't looked into how much the
daemon will do to up/down-convert, but expect that is limited as
well.

I'll put together a patch for the XMMS esd plugin, but I
need to look into portability issues for the endiness test and
optimal byte swapping, any suggestions?  It could also
use an unsigned->signed conversion.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Takashi Oe]

On Mon, 7 Aug 2000, Henry Worth wrote:

> It looks like esd is going for simplicity. Since they are mixing
> digital sound streams to integrate sound sources on the desktop,
> they ultimately need to get all the incoming data streams into native
> endiness to do the mixing. I assume they just chose to put the
> burden on the clients (I'll be charitable and not assume LE blindness
> and that the setting to native endiness was a quick hack when the
> endiness issue was brought to their attention). They would also
> need common sample rates, but I haven't looked into how much the
> daemon will do to up/down-convert, but expect that is limited as
> well.
>
> I'll put together a patch for the XMMS esd plugin, but I
> need to look into portability issues for the endiness test and
> optimal byte swapping, any suggestions?  It could also
> use an unsigned->signed conversion.

Ultimately, byte swapping and conversion should take place in esd, but
there is a bit of problems in its API (maybe easily extensible but it
looks convoluted somehow), and API change will break the binary
compatibility with the existing apps quite possibly.  Well, esd is an
alpha app, so the changes are somewhat expected, but...

Anyhow, attached is a quick hack to the xmms' esd plugin (s<->u conv is
completely untested).


Takashi Oe

--- xmms-1.2.2.ORIG/Output/esd/audio.c	Sat Jul  8 09:35:11 2000
+++ xmms-1.2.2-000807/Output/esd/audio.c	Mon Aug  7 23:58:25 2000
@@ -31,6 +31,7 @@
 static gchar *hostname;
 static pthread_t buffer_thread;
 static gboolean realtime = FALSE;
+static void *(*esd_translate)(void *, gint);

 static gint get_latency(void)
 {
@@ -73,20 +74,78 @@
 	return amount;
 }

+static void *esd_stou8(void *data, gint length)
+{
+	int len = length;
+	unsigned char *dat = (unsigned char *)data;
+
+	while (len-- > 0)
+		*dat++ ^= 0x80;
+
+	return data;
+}
+
+static void *esd_utos16sw(void *data, gint length)
+{
+	int len = length;
+	unsigned char *dat = (unsigned char *)data;
+	unsigned short sdat;
+
+	while (len >= 2) {
+		sdat = (dat[0] << 8 | dat[1]) ^ 0x8000;
+		*dat++ = sdat & 0xff;
+		*dat++ = (sdat >> 8) & 0xff;
+		len -= 2;
+	}
+	return data;
+}
+
+static void *esd_utos16(void *data, gint length)
+{
+	int len = length;
+	unsigned short *sdat = (unsigned short *)data;
+
+	while (len >= 2) {
+		*sdat++ ^= 0x8000;
+		len -= 2;
+	}
+	return data;
+}
+
+static void *esd_16sw(void *data, gint length)
+{
+	int len = length;
+	unsigned char *dat = (unsigned char *)data;
+	unsigned short sdat;
+
+	while (len >= 2) {
+		sdat = (dat[0] << 8 | dat[1]);
+		*dat++ = sdat & 0xff;
+		*dat++ = (sdat >> 8) & 0xff;
+		len -= 2;
+	}
+	return data;
+}
+
 static void esdout_setup_format(AFormat fmt,gint rate, gint nch)
 {
+	gboolean swap_sign = FALSE;
+	gboolean swap_16 = FALSE;
+
 	format = fmt;
 	frequency = rate;
 	channels = nch;
 	switch (fmt)
 	{
-		case FMT_U8:
 		case FMT_S8:
+			swap_sign = TRUE;
+		case FMT_U8:
 			esd_format = ESD_BITS8;
 			break;
 		case FMT_U16_LE:
 		case FMT_U16_BE:
 		case FMT_U16_NE:
+			swap_sign = TRUE;
 		case FMT_S16_LE:
 		case FMT_S16_BE:
 		case FMT_S16_NE:
@@ -94,6 +153,29 @@
 			break;
 	}

+#ifdef WORDS_BIGENDIAN
+	if (fmt == FMT_U16_LE || fmt == FMT_S16_LE)
+#else
+	if (fmt == FMT_U16_BE || fmt == FMT_S16_BE)
+#endif
+		swap_16 = TRUE;
+
+	esd_translate = (void*(*)())NULL;
+	if (esd_format == ESD_BITS8) {
+		if (swap_sign == TRUE)
+			esd_translate = esd_stou8;
+	} else {
+		if (swap_sign == TRUE) {
+			if (swap_16 == TRUE)
+				esd_translate = esd_utos16sw;
+			else
+				esd_translate = esd_utos16;
+		} else {
+			if (swap_16 == TRUE)
+				esd_translate = esd_16sw;
+		}
+	}
+
 	bps = rate * nch;
 	if (esd_format == ESD_BITS16)
 		bps *= 2;
@@ -205,7 +287,11 @@
 	}
 	if(effects_enabled() && ep && ep->mod_samples)
 		length = ep->mod_samples(&data,length, input_format, input_frequency, input_channels);
-	output_bytes += write(fd,data,length);
+	if (esd_translate)
+		output_bytes += write(fd,esd_translate(data,length),length);
+	else {
+		output_bytes += write(fd,data,length);
+	}
 }


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

Takashi Oe wrote:
>
>
> Ultimately, byte swapping and conversion should take place in esd, but
> there is a bit of problems in its API (maybe easily extensible but it
> looks convoluted somehow), and API change will break the binary
> compatibility with the existing apps quite possibly.  Well, esd is an
> alpha app, so the changes are somewhat expected, but...

Legacy can be a bitch..., on the other hand it writes my paycheck.

They might manage backwards compatibilty by defaulting to the current
behavior if functions to provide a more complete format description
aren't called. Anyone on the list have connections with the
enlightenment/eSound camp?

> Anyhow, attached is a quick hack to the xmms' esd plugin (s<->u conv is
> completely untested).
>

Thanks, I'll give it a try. Hopefully we can get it propagated back
into the XMMS cvs tree, so this isn't a reoccuring issue.

BTW, I've started debugging the Xmms_CdRead plugin, it abends
the input thread with a corrupted Xlib call. What I've found so
far is that the problem originates in a call that passes data to
the analyzer displays. A parm is getting corrupted on the last
call in a series, it's a constant, so a likely heap corruption.
But of course it only happens if a particular file
(~/xmms/input.c) is compiled with -O2 (gcc 2.95.2) ;-)

Once the offending file is compiled without optimization it plays
CD's fine with the ATAPI CDDA i/f. The analyzer displays just
display fairly uniform noise, would think endiness but the
visualization data handler has a routine to convert to NE (the
.wav input module data displays correctly). This could be related
to the problem that is causing the abend in the call the
analyzer data input call.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

Well, my Pismo which was increasingly unstable this weekend
is now refusing to boot even from the MacOS CD's. So I probably
won't be able to work on this for at least a few days. I'm
hoping it will boot after having the battery out a few hours
(it worked a couple times this weekend) and that
reinitalizing the firmware and MacOS partitions will help,
if that or a full disk initialization doesn't help it will
probably be off to the shop.

But, just before it powered itself off last night, I found
the likely cause of the abends from the xmms_CdRead plugin.
It's actually in the xmms package code in ~/xmms/input.c. I
don't have the sources available, but can describe the
problem for anyone who's interested in trying to fix it.

There is a routine near the top of the file that uses GTK
byte swapping macros to perform the LE to NE conversion.
The problem is the classic macro mistake of passing
complex expressions with side effects as macro parms. In
this case it's of the form something like (this is from
memory):

  left[i] = GINT16_FROM_LE( (*ptr++) );
  right[i] = GINT16_FROM_LE( (*ptr++) );

The macro expands to use the argument several times
(see the *SWAP* macros in glib.h), so the pointer is
incremented too many times causing a seg fault. The
non-optimized case just happened to have enough readable
memory following the buffer to not fault (and optimizations
on the loop probably had impacts as well), similarly the
.wav player plugin uses a different buffering scheme that
just accidentally avoids faults (likewise the x86 was probably
lucky due to different run-time conditions, provided the
MACRO doesn't simply end up a NOP).

The fix is to find all such occurences and do the incrementing
outside the macro call. I think I've seen similar code in other
parts of the package, so a general inspection is in order. This
should also fix the visualization displays and make the xmms_CdRead
plugin usable for the analog CD challenged Macs.

Good Luck,
Henry


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Iain Sandoe]

n  Mon, Aug 7, 2000, Henry Worth  wrote:
> On Mon, 7 Aug 2000, Iain Sandoe wrote:
>
>> On  Mon, Aug 7, 2000,  Henry Worth  wrote:
>> >
>> > 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.
>
> In the case of the esd daemon it does the ioctls to set the format
> to signed native endiness, and they even do some error checking.

OK. so the facilities of the driver are irrelevant when using esd.

You must make sure that everything you present to esd is native-endian and
signed :-)

which is what I meant by other solutions .... below...

>
>> 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).
>
> It looks like esd is going for simplicity. Since they are mixing
> digital sound streams to integrate sound sources on the desktop,
> they ultimately need to get all the incoming data streams into native
> endiness to do the mixing.

Well, I suppose, (being picky :-) it doesn't have to be the native-endian -
just the *same* for all the items to be mixed...

>I assume they just chose to put the
> burden on the clients (I'll be charitable and not assume LE blindness
> and that the setting to native endiness was a quick hack when the
> endiness issue was brought to their attention). They would also
> need common sample rates, but I haven't looked into how much the
> daemon will do to up/down-convert, but expect that is limited as
> well.

In the case of a mixing deamon like this it is OK, (as I was driving at
above) - *providing* that the clients have some way of "knowing" the
requirement on their outputs.

You've specified it - "all input to esd must be native-endian".

So you must supply the conversion prior to sending it to esd.

> I'll put together a patch for the XMMS esd plugin, but I
> need to look into portability issues for the endiness test and
> optimal byte swapping, any suggestions?  It could also
> use an unsigned->signed conversion.

I'm not sure you can "fix" this - it seems to be a design decision - which
may make that plug unsuitable for your application - but it is still
notionally 'correct' in terms of its own implementation.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

A bit of a misunderstanding seems to have crept in. The
XMMS output plugins are responsible for converting the
data from the input plugin, which could be any standard
audio format for the general purpose audio plugins, to
one supported by the output destination (the esd daemon
in the case of the esd output plugin).

The XMMS framework itself cares little about the data format,
it could be just about anything, audio, video, image,.... Just
so the input and output plugins are agreeable to each other
(and any special effects plugins in use) and can pass that data
between each other on the defined interfaces.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

References: <398A91CA.F8D3C489@student.ethz.ch>

Michel Dänzer wrote:
>
> Henry Worth wrote:
>
> > Rebuilding the kernel to use SCSI generic devices with IDE SCSI
> > emulation produced much better, even usable, results. At startup
> > there are still a couple of dropouts in the first few seconds,
> > but after that the playback is clean across multiple tracks (even
> > with a concurrent kernel compile). Piping cdparanoia to /dev/null
> > shows data rates of 187sectors/sec at all -S settings (and default).
> > From the the drive's spin-up sounds it seems to always be in
> > high-speed mode, but unlike the ATAPI driver, there is little
> > head movement noise.
>
> Does it also improve audio grabbing? With 2.2.15, both IDE and SCSI emulation
> almost killed the system...
>

Haven't seen any instability between the two interfaces
(2.2.17pre15-ben1, though I have had a number of sponstaneous
powerdowns when using the modem this weekend -- the PMU gets testy
when it doesn't get immediate attention, a problem with at least the
recent kernels -- haven't used the modem much with the early
Pismo capable kernels). With cdparanoia's error correction enabled
the SCSI interface is about 30-50% faster ripping tracks (~2-3X). With
the error correction disabled (-Z), both interfaces are the same
speed (~6X) and I get files that compare identically.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Iain Sandoe]

Hi Henry,
 Sun, Aug 6, 2000, Henry Worth wrote:
> Iain Sandoe wrote:

>> I've been using the xmms CVS tree (www.xmms.org and follow the links).  It
>> works fine with .wavs of different sample rates etc.  [xmms --version ==
>> 1.2.1].

> Which output plugin do you use?  And was that on a Pismo?

OSS - and no, but on several different machines (I don't yet have a pismo -
my portable is a Lombard).

You, Matthias & Ben are (at the moment) chief pismo sound testers :-)

> Looking at eSound and the XMMS ESD output plugin, they simply can't work
> with little endian formats like .wav on a big endian machine. The esd
> daemon
> uses, and sets the output device to, native endiness (there isn't even a
> parm to indicate endiness of the incoming data buffer). The XMMS ESD
> output plugin completely ignores endiness of the incoming data stream
> and
> passes it through unchanged (versions 0.9.5, 1.2.1, 1.2.2). A quick hack
> to swap bytes in the ESD plugin fixed playback of .wav files. The small
> files that had worked before were all 8-bit mono format.

OK - there's a lot of this in apps that came from x86 - they assume that the
output is LE.

If you use my back-port - I "fixed" (kludged) the default dsp settings to
44.1k, 16 bit , stereo LE -- to be compatible with x86 progs that don't
bother to set things up :-(

> OTOH, the OSS output plugin appears to correctly pass the data stream's
> endiness to the sound device, but a quick hack to swap data bytes also
> fixed its playback problems.

??? this is strange - if it tells the truth (endianess, sample rate, depth &
stereo/mono) - I think it should work...  there's no need to swap bytes at
all with the audio - the hardware can do it...

> I need to dig into the code some more, but
> are we sure the AWACS Screamer in the Pismo isn't one of those variants
> that only supports big-endian data?

This is news to me see below.... (have you any reference for this issue?)

> A quick test forcing the
> AFMT_*_[LB]E
> value to either value for the IOCTL doesn't make a difference.

The awacs, screamer and burgundy chips *all* have an endian-swap capability
AFAICT.  So, providing you tell the driver what you are supplying - it will
work OK:

""If you set dmasound_awacs to the *correct settings for the data you pass
to it* - it works.""

I have tested (yesterday - on a screamer) with:
44.1k LE stereo
22050 LE stereo
11025 A & mu Mono
8000 mu (into /dev/audio as well)

I'll increase the coverage as/when I have time (it was incidental to some
other testing).

What you could send me that would be *very* helpful is:

a dump of any device-tree contents that relate to sound.

I need to be able to try and build different mixer abstractions on the basis
of which machine we have - because this is where most of our difficulty
lies.

========

There is a residual "gottcha".

If you machine *only* supports 44.1k playback (we shall see - from
device-tree sample-rates stuff)... then:

If you try and playback low sample rate stuff, it needs to be "up-converted"
to 44.1k.

The kernel driver can only afford to implement a fairly simple algorithm for
this... and it is, for that reason, fairly 'nasty' in sound.

You would be much better off using some off-line process (which can make use
of FP) to do the up-conversions.

other than that - I can, at the moment (at least with the back-port) see no
reason why the sound output will not work properly.

Getting sound in-out to work is a different matter (I believe you have no CD
connection through the screamer no?)

HTH
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Takashi Oe]

Hi,

On Sun, 6 Aug 2000, Iain Sandoe wrote:

> OK - there's a lot of this in apps that came from x86 - they assume that the
> output is LE.

Is this really true?  What I have experienced over the years is quite the
opposite.  It is true that apps developed on x86 usually set the Linux
driver to accept AFMT_S16_LE; however, they often supply BE data on ppc
and LE data on x86.  For this reason, many apps from x86 camp just work if
AFMT_S16_LE in their codes were changed to AFMT_S16_NE.

>
> If you use my back-port - I "fixed" (kludged) the default dsp settings to
> 44.1k, 16 bit , stereo LE -- to be compatible with x86 progs that don't
> bother to set things up :-(

For those apps, AFMT_S16_BE as a default is more appropriate for the
reason above IMHO.

[...]
> > A quick test forcing the
> > AFMT_*_[LB]E
> > value to either value for the IOCTL doesn't make a difference.
>
> The awacs, screamer and burgundy chips *all* have an endian-swap capability
> AFAICT.  So, providing you tell the driver what you are supplying - it will
> work OK:

AWACS on NuBus PowerMacs doesn't support the byte swapping even though it
has the same revision number (2) as AWACS found on early PCI PowerMacs
which do support the byte swapping.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

Iain Sandoe wrote:
>
> Hi Henry,
>  Sun, Aug 6, 2000, Henry Worth wrote:
> > Iain Sandoe wrote:
>
> >> I've been using the xmms CVS tree (www.xmms.org and follow the links).  It
> >> works fine with .wavs of different sample rates etc.  [xmms --version ==
> >> 1.2.1].
>
> > Which output plugin do you use?  And was that on a Pismo?
>
> OSS - and no, but on several different machines (I don't yet have a pismo -
> my portable is a Lombard).
>
> You, Matthias & Ben are (at the moment) chief pismo sound testers :-)
>
> > Looking at eSound and the XMMS ESD output plugin, they simply can't work
> > with little endian formats like .wav on a big endian machine. The esd
> > daemon
> > uses, and sets the output device to, native endiness (there isn't even a
> > parm to indicate endiness of the incoming data buffer). The XMMS ESD
> > output plugin completely ignores endiness of the incoming data stream
> > and
> > passes it through unchanged (versions 0.9.5, 1.2.1, 1.2.2). A quick hack
> > to swap bytes in the ESD plugin fixed playback of .wav files. The small
> > files that had worked before were all 8-bit mono format.
>
> OK - there's a lot of this in apps that came from x86 - they assume that the
> output is LE.
>
> If you use my back-port - I "fixed" (kludged) the default dsp settings to
> 44.1k, 16 bit , stereo LE -- to be compatible with x86 progs that don't
> bother to set things up :-(

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).
Niether one does any form of data conversion.

>
> > OTOH, the OSS output plugin appears to correctly pass the data stream's
> > endiness to the sound device, but a quick hack to swap data bytes also
> > fixed its playback problems.
>
> ??? this is strange - if it tells the truth (endianess, sample rate, depth &
> stereo/mono) - I think it should work...  there's no need to swap bytes at
> all with the audio - the hardware can do it...
>
> > I need to dig into the code some more, but
> > are we sure the AWACS Screamer in the Pismo isn't one of those variants
> > that only supports big-endian data?
>
> This is news to me see below.... (have you any reference for this issue?)

There is a past discussion on this in the archives (it may have
concerned
Takashi Oe's case of the NuBus P'Macs). A remote possiblity is something
has changed in the register mappings, or that this masking of the chip
is broken and Apple decided to ship it and work around the problem in SW
(a hardware designer's two most common phrases: "fix it in software" and
"software is easy:).

>
> > A quick test forcing the
> > AFMT_*_[LB]E
> > value to either value for the IOCTL doesn't make a difference.
>
> The awacs, screamer and burgundy chips *all* have an endian-swap capability
> AFAICT.  So, providing you tell the driver what you are supplying - it will
> work OK:
>
> ""If you set dmasound_awacs to the *correct settings for the data you pass
> to it* - it works.""

Using the OSS sound plugin with the hacks to force data to big endian
and
to hardcode just the IOCTL to different AFMT_ values; the only 16 bit
format
that didn't play back correctly was AFMT_U16_BE (very distorted, but
recognizable). Here the /dev/sndstat outputs from the four runs:

PowerMac (AWACS rev 3) DMA sound driver:
	sound.format = 0x20 (signed 16 bit big)
	sound.speed = 44100Hz (phys. 44100Hz)
	sound.stereo = 0x1 (stereo)
	sq.block_size = 4096 sq.max_count = 4 sq.max_active = 4
	sq.count = 0 sq.rear_size = 2048
	sq.playing = 0 sq.syncing = 0
[root@localhost linux]# cat /dev/sndstat
PowerMac (AWACS rev 3) DMA sound driver:
	sound.format = 0x10 (signed 16 bit little)
	sound.speed = 44100Hz (phys. 44100Hz)
	sound.stereo = 0x1 (stereo)
	sq.block_size = 4096 sq.max_count = 4 sq.max_active = 4
	sq.count = 4 sq.rear_size = 2048
	sq.playing = 2 sq.syncing = 0
[root@localhost linux]# cat /dev/sndstat
PowerMac (AWACS rev 3) DMA sound driver:
	sound.format = 0x80 (unsigned 16 bit little)
	sound.speed = 44100Hz (phys. 44100Hz)
	sound.stereo = 0x1 (stereo)
	sq.block_size = 4096 sq.max_count = 4 sq.max_active = 4
	sq.count = 4 sq.rear_size = 2048
	sq.playing = 2 sq.syncing = 0
[root@localhost linux]# cat /dev/sndstat
PowerMac (AWACS rev 3) DMA sound driver:
	sound.format = 0x100 (unsigned 16 bit big)
	sound.speed = 44100Hz (phys. 44100Hz)
	sound.stereo = 0x1 (stereo)
	sq.block_size = 4096 sq.max_count = 4 sq.max_active = 4
	sq.count = 4 sq.rear_size = 2048
	sq.playing = 2 sq.syncing = 0

I've had the same results with both /dev/audio and /dev/dsp.


>
> I have tested (yesterday - on a screamer) with:
> 44.1k LE stereo
> 22050 LE stereo
> 11025 A & mu Mono
> 8000 mu (into /dev/audio as well)
>
> I'll increase the coverage as/when I have time (it was incidental to some
> other testing).
>

I saw your test program post, I'll merge in your p15b1 patch later today
and give it a try.

> What you could send me that would be *very* helpful is:
>
> a dump of any device-tree contents that relate to sound.


pci@f2000000/mac-io@17/davbus@14000/sound:
name             "sound"
device_type      "soundchip"
compatible       "screamer"
                 "awacs"
                 ""
model            "343S0184"
vendor-id        0000106b (4203)
device-id        0000000a (10)
#-detects        00000003
#-inputs         00000006
#-features       00000001
#-outputs        00000002
object-model-version 00000001
sub-frame        00000000
icon-id          ffffbf4d (-16563)
info-id          ffffbf44 (-16572)
name-id          ffffbf4d (-16563)
sample-rates     00000002 56220000 ac440000
default-monitor  6e6f6e65 (1852796517)


I take it that it supports only 22K and 44.1K sample rates?

Another problem that I've run into in trying various versions
of XMMS and eSound, is that any of the newer eSound RPM or SRPM
packages I've tried, other than the 0.2.17 RPM in LPPC2K,
have all played back at very high speed (with 44.1k samples).
Not just with XMMS, but esdplay as well, haven't pursued it yet.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Takashi Oe]

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

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.

Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Iain Sandoe]

[...]
>>From the the drive's spin-up sounds it seems to always be in
>>high-speed mode, but unlike the ATAPI driver, there is little
>>head movement noise.
>
> I think the problem is more with cdparanoia. I think it's more or less
> synchronous, it doesn't have a thread that collects datas while another
> outputs sounds. I've looked at cdparanoia sources some time ago, and I
> think and intermediate step of buffering is necessary.

>From my IRQ latency measurements I would think that there was *no* chance
without the intermediate step.  On my Lombard, CD access over IDE can mask
IRQs for 2 >>ms<<<  which also means you need to make sure the audio frag
sizes are sensible as well... i.e. don't try 2 frags of 256 bytes - it won't
work as things stand.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Benjamin Herrenschmidt]

>
>Using the ATAPI CD drivers there are underruns with significant
>dropouts every couple of seconds. Various hdparms and cdparanoia
>parms were tried with no significant change. These include various
>transfers modes and cdparanoia's buffer (-n) and speed (-S)
>parms and various data formats. Piping cdparanoia out to /dev/null
>showed data rates of 46 sectors/sec at -S1, 65sps at -S8, and
>133sps at -S12 and above (also the default and no significant
>changes with different transfer modes and -n values). At the higher
>speeds (>-S11) there is a high-level of continuous head-seek noise,
>suggesting a lot of overruns and reseeks on the CD i/f side.
>
>Rebuilding the kernel to use SCSI generic devices with IDE SCSI
>emulation produced much better, even usable, results. At startup
>there are still a couple of dropouts in the first few seconds,
>but after that the playback is clean across multiple tracks (even
>with a concurrent kernel compile). Piping cdparanoia to /dev/null
>shows data rates of 187sectors/sec at all -S settings (and default).
>From the the drive's spin-up sounds it seems to always be in
>high-speed mode, but unlike the ATAPI driver, there is little
>head movement noise.

I think the problem is more with cdparanoia. I think it's more or less
synchronous, it doesn't have a thread that collects datas while another
outputs sounds. I've looked at cdparanoia sources some time ago, and I
think and intermediate step of buffering is necessary.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Iain Sandoe]

Hi Henry,
 Fri, Aug 4, 2000, Henry Worth wrote:
> Additionally there seems to be some clipping occuring somewhere
> in the A/D or mixer/preamp. It's independent of output
> volume on either the internal speakers or external port, and
> only occurs, consistently, on a few tracks I've tried. But in
> general using .aiff format instead of .wav seems to sound a
> bit better, with perhaps a bit less clipping (haven't tried
> the latest damsound patches).

The latest patches will (probably) not help this... although the output from
them will help me in debugging where we're at - and they do fix on or two
other pismo-related issues.

it is likely (a) either the app not really setting up /dev/dsp properly. or
(b) issues with the mixer abstraction which are still being worked on.

Try opening the oss mixer (e.g. kmixer) and making sure that the monitoring
channel is full *up*.  I know this sounds strange (but at least with CDs)
for me it stops the distortion.

This stuff is being actively worked on... and I will post with patch/URL
if/when the results are more positive.

> I'd like to give XMMS a try, but the XMMS in LPPC2K and updates
> and builds of newer versions all generate white noise on .wav
> files (endiness?). Has anyone been able to get XMMS to work on
> a Pismo? And where can I find the XMMS CDDA playback plugin?

I've been using the xmms CVS tree (www.xmms.org and follow the links).  It
works fine with .wavs of different sample rates etc.  [xmms --version ==
1.2.1].

I don't think the 'standard' CD plugin routes the audio from disk to
/dev/dsp -- it seems to do the same as other media players and start the CD
player but use the local routing of audio on the mixer.  will check some
more on this.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

On Fri, 4 Aug 2000, Iain Sandoe wrote:

> Hi Henry,
>  Fri, Aug 4, 2000, Henry Worth wrote:
> > Additionally there seems to be some clipping occuring somewhere
> > in the A/D or mixer/preamp. It's independent of output
> > volume on either the internal speakers or external port, and
> > only occurs, consistently, on a few tracks I've tried. But in
> > general using .aiff format instead of .wav seems to sound a
> > bit better, with perhaps a bit less clipping (haven't tried
> > the latest damsound patches).
>
> The latest patches will (probably) not help this... although the output from
> them will help me in debugging where we're at - and they do fix on or two
> other pismo-related issues.
>
> it is likely (a) either the app not really setting up /dev/dsp properly. or
> (b) issues with the mixer abstraction which are still being worked on.
>
> Try opening the oss mixer (e.g. kmixer) and making sure that the monitoring
> channel is full *up*.  I know this sounds strange (but at least with CDs)
> for me it stops the distortion.

I've about decided the "clipping" is mostly on the CDs (it's heavily
picked acoustic string stuff), it's just more noticeable when
listening hard for problems (and in particular through those
tinny internal spearkers).

>
> This stuff is being actively worked on... and I will post with patch/URL
> if/when the results are more positive.
>
> > I'd like to give XMMS a try, but the XMMS in LPPC2K and updates
> > and builds of newer versions all generate white noise on .wav
> > files (endiness?). Has anyone been able to get XMMS to work on
> > a Pismo? And where can I find the XMMS CDDA playback plugin?
>
> I've been using the xmms CVS tree (www.xmms.org and follow the links).  It
> works fine with .wavs of different sample rates etc.  [xmms --version ==
> 1.2.1].

I've been trying 1.2.2 binary and source RPM's. Oddly the smaller wavs
in /usr/share/sound that the gnome desktop uses play ok, but just the
the ones that show a 0:00 length in the playlist. Longer ones just
generate noise (but play ok with other players). Have the same problem
with the version in LPPC2K (IIRC, 1.1.6 or 1.1.7). This is with both oss
and esd output modules. I'll have to check lib dependencies, something
is amiss.

>
> I don't think the 'standard' CD plugin routes the audio from disk to
> /dev/dsp -- it seems to do the same as other media players and start the CD
> player but use the local routing of audio on the mixer.  will check some
> more on this.
>

There has been mention of a CDDA plug-in that doesn't work
very well. I took another look at www.xmms.org and found one that
looked like it might be it, but I go back a few minutes later
to get the name and it's not on the list, just the newer plugins...
Plugin list and new plugin list have same URL..., clearing my cache
doesn't help so the server's cache must be confused as well. Check
history and get the earlier response URL... there it is:

Xmms_CdRead from ftp://mud.stack.nl/pub/OuterSpace/willem/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Benjamin Herrenschmidt]

>I've about decided the "clipping" is mostly on the CDs (it's heavily
>picked acoustic string stuff), it's just more noticeable when
>listening hard for problems (and in particular through those
>tinny internal spearkers).

Sound was good here (Sawtooth G4/350), however, I found that the playback
using cdparanoia used 25-50% of my CPU, caused huge latencies (mouse
blocked in X for half a second every 3 or 4 seconds, etc...)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

Iain Sandoe wrote:
>
>
> I've been using the xmms CVS tree (www.xmms.org and follow the links).  It
> works fine with .wavs of different sample rates etc.  [xmms --version ==
> 1.2.1].
>

Which output plugin do you use?  And was that on a Pismo?

Looking at eSound and the XMMS ESD output plugin, they simply can't work
with little endian formats like .wav on a big endian machine. The esd
daemon
uses, and sets the output device to, native endiness (there isn't even a
parm to indicate endiness of the incoming data buffer). The XMMS ESD
output plugin completely ignores endiness of the incoming data stream
and
passes it through unchanged (versions 0.9.5, 1.2.1, 1.2.2). A quick hack
to swap bytes in the ESD plugin fixed playback of .wav files. The small
files that had worked before were all 8-bit mono format.

OTOH, the OSS output plugin appears to correctly pass the data stream's
endiness to the sound device, but a quick hack to swap data bytes also
fixed its playback problems. I need to dig into the code some more, but
are we sure the AWACS Screamer in the Pismo isn't one of those variants
that only supports big-endian data? A quick test forcing the
AFMT_*_[LB]E
value to either value for the IOCTL doesn't make a difference.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

CDDA playback on Pismo (and other newer models)

[Henry Worth]

As most of you know, the newer Mac models lack analog CD playback
capabilities. So I've been experimenting with using cdparanoia
piped through play for CD playback on my Pismo with
2.2.17pre15-ben1 (btw, very stable so far).

Using the ATAPI CD drivers there are underruns with significant
dropouts every couple of seconds. Various hdparms and cdparanoia
parms were tried with no significant change. These include various
transfers modes and cdparanoia's buffer (-n) and speed (-S)
parms and various data formats. Piping cdparanoia out to /dev/null
showed data rates of 46 sectors/sec at -S1, 65sps at -S8, and
133sps at -S12 and above (also the default and no significant
changes with different transfer modes and -n values). At the higher
speeds (>-S11) there is a high-level of continuous head-seek noise,
suggesting a lot of overruns and reseeks on the CD i/f side.

Rebuilding the kernel to use SCSI generic devices with IDE SCSI
emulation produced much better, even usable, results. At startup
there are still a couple of dropouts in the first few seconds,
but after that the playback is clean across multiple tracks (even
with a concurrent kernel compile). Piping cdparanoia to /dev/null
shows data rates of 187sectors/sec at all -S settings (and default).
>From the the drive's spin-up sounds it seems to always be in
high-speed mode, but unlike the ATAPI driver, there is little
head movement noise.

So, any thoughts as to whether this a lack of sufficent buffering
in the CDDA path of the ATAPI CD driver? Or, more general
performance problems in the ATAPI CD or low-level drivers?

I'll also be looking at cdparanoia (v9.7), it does diffentiate
between ATAPI and SCSI interfaces, so it might not be reading
ATAPI devices in an optimal manner. I'll also be giving cdda2wav
a try now that I have SCSI emulation built in (btw, you don't
need to leave the ATAPI cd driver out of the build, just use
the hd[n]=ide-scsi boot parm to switch).

Additionally there seems to be some clipping occuring somewhere
in the A/D or mixer/preamp. It's independent of output
volume on either the internal speakers or external port, and
only occurs, consistently, on a few tracks I've tried. But in
general using .aiff format instead of .wav seems to sound a
bit better, with perhaps a bit less clipping (haven't tried
the latest damsound patches).

I'd like to give XMMS a try, but the XMMS in LPPC2K and updates
and builds of newer versions all generate white noise on .wav
files (endiness?). Has anyone been able to get XMMS to work on
a Pismo? And where can I find the XMMS CDDA playback plugin?

TIA,
Henry

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Michel Dänzer]

Henry Worth wrote:

> Rebuilding the kernel to use SCSI generic devices with IDE SCSI
> emulation produced much better, even usable, results. At startup
> there are still a couple of dropouts in the first few seconds,
> but after that the playback is clean across multiple tracks (even
> with a concurrent kernel compile). Piping cdparanoia to /dev/null
> shows data rates of 187sectors/sec at all -S settings (and default).
> From the the drive's spin-up sounds it seems to always be in
> high-speed mode, but unlike the ATAPI driver, there is little
> head movement noise.

Does it also improve audio grabbing? With 2.2.15, both IDE and SCSI emulation
almost killed the system...


Michel


--
Columbus had a fourth ship. It sailed over the edge.
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Nelson Abramson]

Henry Worth wrote:

> <snip>
> Using the ATAPI CD drivers there are underruns with significant
> dropouts every couple of seconds. Various hdparms and cdparanoia
> parms were tried with no significant change. These include various

<snip>

I had issues using the "cdparanoia 1- - | play - -t WAV" until I realized
that cdparanaoia was trying to do on the fly error correcting, resulting
in the pause every few seconds.  By using the "-Z" flag, which turned off
the error correcting, I got excellent playback with no skips what-so-ever
on my Pismo.

HTH
--Nelson Abramson


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CDDA playback on Pismo (and other newer models)

[Henry Worth]

On Fri, 4 Aug 2000, Nelson Abramson wrote:

> Henry Worth wrote:
>
> > <snip>
> > Using the ATAPI CD drivers there are underruns with significant
> > dropouts every couple of seconds. Various hdparms and cdparanoia
> > parms were tried with no significant change. These include various
>
> <snip>
>
> I had issues using the "cdparanoia 1- - | play - -t WAV" until I realized
> that cdparanaoia was trying to do on the fly error correcting, resulting
> in the pause every few seconds.  By using the "-Z" flag, which turned off
> the error correcting, I got excellent playback with no skips what-so-ever
> on my Pismo.
>

Thanks, that works great with both the atapi and ide-scsi interfaces.
The sector rates for atapi is 3x what it was before. I still think the
aiff format may sound a tad better, the wav format seems a little
thin in comparison. For aiff the command would be:

cdparanoia 1- -Z -f - | play - -t aiff


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/