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

On  Mon, Aug 7, 2000,  Henry Worth  wrote:

Takashi Oe wrote:

quoted

On Sun, 6 Aug 2000, Henry Worth wrote:

[...]

quoted

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/

On Mon, 7 Aug 2000, Iain Sandoe wrote:

On  Mon, Aug 7, 2000,  Henry Worth  wrote:

quoted

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/

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/

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/