dmasound audio patch

dmasound audio patch

[Bill Fink]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Hi,

A friend of mine, Rob Scott, worked up a patch to the dmasound driver
that fixes some of the PPC endianness issues by doing byte swapping
in the driver.  He uses it on a Titanium PowerBook, and I am using it
on a dual 500 MHz G4 with good results.  Before the patch, using xmms
with the AudioCD Reader plugin, I had to use the esound driver since
the OSS driver just gave static.  Now I can use the OSS driver directly,
so there's no need to run the esd daemon.

I know this patch probably isn't politically correct, since as I understand
it Linus doesn't believe that things such as byte swapping should be done
in the kernel.  But then he lives on a little endian machine and doesn't
need to mess with dozens of broken audio applications.  So if you're not
worried about kernel political correctness, you might want to give this
patch a try.  Of course I make no warranty of any kind, but I can attest
that it works fine on a couple of different PPC systems with BenH kernels
around 2.4.18.

						-Bill

[-- Attachment #2: dmasound.patch --]
[-- Type: application/octet-stream, Size: 2721 bytes --]

diff -ur .orig/dmasound_awacs.c .mod/dmasound_awacs.c
--- .orig/dmasound_awacs.c	Tue Feb 26 09:35:34 2002
+++ .mod/dmasound_awacs.c	Tue Feb 26 23:17:40 2002
@@ -753,6 +753,16 @@
 			dmasound.dsp.size = size;
 		}
 	}
+	else {
+		dmasound.soft.format = req_format;
+		dmasound.soft.size = size;
+		dmasound.hard.format = format;
+		if (dmasound.minDev == SND_DEV_DSP) {
+			dmasound.dsp.format = format;
+			dmasound.dsp.size = size;
+		}
+		format = req_format;
+	}
 
 	return format;
 }
@@ -2692,7 +2702,7 @@
 __init set_hw_byteswap(struct device_node *io)
 {
 	struct device_node *mio ;
-	unsigned int *p, kl = 0 ;
+	unsigned int kl = 0 ;
 
 	/* if seems that Keylargo can't byte-swap  */
 
diff -ur .orig/dmasound_core.c .mod/dmasound_core.c
--- .orig/dmasound_core.c	Tue Feb 26 09:35:34 2002
+++ .mod/dmasound_core.c	Tue Feb 26 23:17:40 2002
@@ -1263,7 +1263,7 @@
 			if (result < 0)
 				return result;
 			if (format != data)
-				return -EINVAL;
+				return -ENOSYS;
 			return 0;
 		} else
 			return -EINVAL ;
diff -ur .orig/trans_16.c .mod/trans_16.c
--- .orig/trans_16.c	Tue Feb 26 09:35:35 2002
+++ .mod/trans_16.c	Tue Feb 26 23:17:40 2002
@@ -163,23 +163,30 @@
 	ssize_t count, used;
 	int stereo = dmasound.soft.stereo;
 	short *fp = (short *) &frame[*frameUsed];
+	short *up = (short *) userPtr;
 
 	frameLeft >>= 2;
 	userCount >>= (stereo? 2: 1);
 	used = count = min_t(unsigned long, userCount, frameLeft);
-	if (!stereo) {
-		short *up = (short *) userPtr;
-		while (count > 0) {
-			short data;
+	while (count > 0) {
+		short data;
+		if (get_user(data, up++))
+			return -EFAULT;
+		if ((dmasound.hard.format == AFMT_S16_BE) && (dmasound.soft.format == AFMT_S16_LE)) {
+			*fp++ = swab16( data );
+		} else {
+			*fp++ = data;
+		}
+		if (stereo) {
 			if (get_user(data, up++))
 				return -EFAULT;
+		}
+		if ((dmasound.hard.format == AFMT_S16_BE) && (dmasound.soft.format == AFMT_S16_LE)) {
+			*fp++ = swab16( data );
+		} else {
 			*fp++ = data;
-			*fp++ = data;
-			count--;
 		}
-	} else {
-		if (copy_from_user(fp, userPtr, count * 4))
-			return -EFAULT;
+		count--;
 	}
 	*frameUsed += used * 4;
 	return stereo? used * 4: used * 2;
@@ -203,13 +210,21 @@
 		if (get_user(data, up++))
 			return -EFAULT;
 		data ^= mask;
-		*fp++ = data;
+		if ((dmasound.hard.format == AFMT_S16_BE) && (dmasound.soft.format == AFMT_S16_LE)) {
+			*fp++ = swab16(data);
+		} else {
+			*fp++ = data;
+		}
 		if (stereo) {
 			if (get_user(data, up++))
 				return -EFAULT;
 			data ^= mask;
 		}
-		*fp++ = data;
+		if ((dmasound.hard.format == AFMT_S16_BE) && (dmasound.soft.format == AFMT_S16_LE)) {
+			*fp++ = swab16(data);
+		} else {
+			*fp++ = data;
+		}
 		count--;
 	}
 	*frameUsed += used * 4;

Re: dmasound audio patch

[Michel Dänzer]

On Sun, 2002-04-07 at 23:23, Bill Fink wrote:
>
> A friend of mine, Rob Scott, worked up a patch to the dmasound driver
> that fixes some of the PPC endianness issues by doing byte swapping
> in the driver.  He uses it on a Titanium PowerBook, and I am using it
> on a dual 500 MHz G4 with good results.  Before the patch, using xmms
> with the AudioCD Reader plugin, I had to use the esound driver since
> the OSS driver just gave static.  Now I can use the OSS driver directly,
> so there's no need to run the esd daemon.

Must be an old version of xmms? It swaps bytes if necessary since 1.2.5
or so.

> I know this patch probably isn't politically correct, since as I understand
> it Linus doesn't believe that things such as byte swapping should be done
> in the kernel.  But then he lives on a little endian machine and doesn't
> need to mess with dozens of broken audio applications.

What are those apps? In my experience, most apps where sound doesn't
work are simply broken and need to be fixed anyhow, no kernel patch can
help that.

For example, the XMMS cdread plugin needs fixing to convert the data to
native endianness anyway because otherwise the filtering for the XMMS EQ
produces noise again.


--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

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

Re: dmasound audio patch

[Bill Fink]

On 08 Apr 2002, Michel Dänzer wrote:

> On Sun, 2002-04-07 at 23:23, Bill Fink wrote:
> >
> > A friend of mine, Rob Scott, worked up a patch to the dmasound driver
> > that fixes some of the PPC endianness issues by doing byte swapping
> > in the driver.  He uses it on a Titanium PowerBook, and I am using it
> > on a dual 500 MHz G4 with good results.  Before the patch, using xmms
> > with the AudioCD Reader plugin, I had to use the esound driver since
> > the OSS driver just gave static.  Now I can use the OSS driver directly,
> > so there's no need to run the esd daemon.
>
> Must be an old version of xmms? It swaps bytes if necessary since 1.2.5
> or so.

Hi Michel,

That's good to know.  I was using xmms-1.2.4 that came with YDL 2.1,
but I see that YDL 2.2 has xmms-1.2.5, so I'll give that a try.

						-Thanks

						-Bill

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

Re: dmasound audio patch

[Michel Dänzer]

On Mon, 2002-04-08 at 14:41, Bill Fink wrote:
> On 08 Apr 2002, Michel Dänzer wrote:
>
> > On Sun, 2002-04-07 at 23:23, Bill Fink wrote:
> > >
> > > A friend of mine, Rob Scott, worked up a patch to the dmasound driver
> > > that fixes some of the PPC endianness issues by doing byte swapping
> > > in the driver.  He uses it on a Titanium PowerBook, and I am using it
> > > on a dual 500 MHz G4 with good results.  Before the patch, using xmms
> > > with the AudioCD Reader plugin, I had to use the esound driver since
> > > the OSS driver just gave static.  Now I can use the OSS driver directly,
> > > so there's no need to run the esd daemon.
> >
> > Must be an old version of xmms? It swaps bytes if necessary since 1.2.5
> > or so.
>
> Hi Michel,
>
> That's good to know.  I was using xmms-1.2.4 that came with YDL 2.1,
> but I see that YDL 2.2 has xmms-1.2.5, so I'll give that a try.

Hmm, looking at our xmms changelog, the endianness fixes may only be in
1.2.6 or later. YMMV.


--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

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

Re: dmasound audio patch

[Bill Fink]

On 08 Apr 2002, Michel Dänzer wrote:

> On Mon, 2002-04-08 at 14:41, Bill Fink wrote:
> > On 08 Apr 2002, Michel Dänzer wrote:
> >
> > > Must be an old version of xmms? It swaps bytes if necessary since 1.2.5
> > > or so.
> >
> > Hi Michel,
> >
> > That's good to know.  I was using xmms-1.2.4 that came with YDL 2.1,
> > but I see that YDL 2.2 has xmms-1.2.5, so I'll give that a try.
>
> Hmm, looking at our xmms changelog, the endianness fixes may only be in
> 1.2.6 or later. YMMV.

Well even the just released YDL 2.2 only has xmms-1.2.5, which is still
broken.  For the record, I did get the Rawhide xmms-1.2.7 source RPM and
did an "rpm --rebuild" on it, and can report that xmms-1.2.7 does in fact
work fine, but that was a fair amount of work and time.  I'm still going
to stick with my friend's dmasound kernel patch, so I don't have to go
through all this for the next sound app I might happen to try that's not
yet endianness aware.

						-Thanks

						-Bill

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

Re: dmasound audio patch

[Bill Fink]

On Mon, 8 Apr 2002, Bill Fink wrote:

> On 08 Apr 2002, Michel Dänzer wrote:
>
> > On Sun, 2002-04-07 at 23:23, Bill Fink wrote:
> > >
> > > A friend of mine, Rob Scott, worked up a patch to the dmasound driver
> > > that fixes some of the PPC endianness issues by doing byte swapping
> > > in the driver.  He uses it on a Titanium PowerBook, and I am using it
> > > on a dual 500 MHz G4 with good results.  Before the patch, using xmms
> > > with the AudioCD Reader plugin, I had to use the esound driver since
> > > the OSS driver just gave static.  Now I can use the OSS driver directly,
> > > so there's no need to run the esd daemon.
> >
> > Must be an old version of xmms? It swaps bytes if necessary since 1.2.5
> > or so.
>
> Hi Michel,
>
> That's good to know.  I was using xmms-1.2.4 that came with YDL 2.1,
> but I see that YDL 2.2 has xmms-1.2.5, so I'll give that a try.
>
> 						-Thanks
>
> 						-Bill

Hmmm.  I just tried xmms-1.2.5 and got:

% xmms
/usr/lib/xmms/Input/libcdread.so: undefined symbol: playlist_position

I then updated to xmms-cdread-0.11d, but when I tried playing a CD
with the OSS output driver, I still got static.

This is already getting much more trouble than it's worth, and this
is just one app.  I'll stick with my friend's dmasound kernel patch,
which works just fine for the apps I generally use.

						-Bill

P.S.  There didn't seem to be *ANY* xmms-cdread PPC RPM with YDL 2.2,
      let alone an updated one (I got the xmms-cdread-0.11d PPC RPM
      from LinuxPPC Contribs).

P.P.S.  Another thing I noticed missing from YDL 2.2 is mozilla-chat.

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

Re: dmasound audio patch

[Benjamin Herrenschmidt]

>Hi,
>
>A friend of mine, Rob Scott, worked up a patch to the dmasound driver
>that fixes some of the PPC endianness issues by doing byte swapping
>in the driver.  He uses it on a Titanium PowerBook, and I am using it
>on a dual 500 MHz G4 with good results.  Before the patch, using xmms
>with the AudioCD Reader plugin, I had to use the esound driver since
>the OSS driver just gave static.  Now I can use the OSS driver directly,
>so there's no need to run the esd daemon.
>
>I know this patch probably isn't politically correct, since as I understand
>it Linus doesn't believe that things such as byte swapping should be done
>in the kernel.  But then he lives on a little endian machine and doesn't
>need to mess with dozens of broken audio applications.  So if you're not
>worried about kernel political correctness, you might want to give this
>patch a try.  Of course I make no warranty of any kind, but I can attest
>that it works fine on a couple of different PPC systems with BenH kernels
>around 2.4.18.

Hi Bill, thanks for the patch, though I decided long ago I agree with linus
and that swapping shouldn't take place in the kernel. If we go that way, we
make sure userland apps will never be fixed ;)

Ben.

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

Re: dmasound audio patch

[Bill Fink]

On Sat, 15 Jul 2034, Benjamin Herrenschmidt wrote:

Hi Ben,

Gee you're a very futuristic kind of guy (see timestamp above).  :-)

> Hi Bill, thanks for the patch, though I decided long ago I agree with linus
> and that swapping shouldn't take place in the kernel. If we go that way, we
> make sure userland apps will never be fixed ;)

I halfway understand the reasoning but I don't really agree with it.
I don't see any significant problem with doing the byte swapping in
the kernel.  From an engineering standpoint, it seems to make more
sense to me to do this common function once in the kernel driver rather
than redoing it over and over in every audio app, and keep getting bit
by the same endianness problem over and over again.  Linus and the PC
world don't have to worry about it, but us PPC types keep getting a
delay in usable audio apps as a result.

Oh well, I know I'm tilting at windmills here.  :-)

						-Bill

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

Re: dmasound audio patch

[Benjamin Herrenschmidt]

>I halfway understand the reasoning but I don't really agree with it.
>I don't see any significant problem with doing the byte swapping in
>the kernel.  From an engineering standpoint, it seems to make more
>sense to me to do this common function once in the kernel driver rather
>than redoing it over and over in every audio app, and keep getting bit
>by the same endianness problem over and over again.  Linus and the PC
>world don't have to worry about it, but us PPC types keep getting a
>delay in usable audio apps as a result.
>
>Oh well, I know I'm tilting at windmills here.  :-)

No, here you are hitting the lack of proper audio architecture
in linux ;)

It's not the kernel work, definitely, to do any munging on samples
even if it is as simple as byteswap. It's the role of a userland
based process to do mixing & format conversion. I hope alsa will
finally provide something around those lines.

Ben.


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

Re: dmasound audio patch

[Bill Fink]

On Mon, 8 Apr 2002, Benjamin Herrenschmidt wrote:

> >I halfway understand the reasoning but I don't really agree with it.
> >I don't see any significant problem with doing the byte swapping in
> >the kernel.  From an engineering standpoint, it seems to make more
> >sense to me to do this common function once in the kernel driver rather
> >than redoing it over and over in every audio app, and keep getting bit
> >by the same endianness problem over and over again.  Linus and the PC
> >world don't have to worry about it, but us PPC types keep getting a
> >delay in usable audio apps as a result.
> >
> >Oh well, I know I'm tilting at windmills here.  :-)
>
> No, here you are hitting the lack of proper audio architecture
> in linux ;)
>
> It's not the kernel work, definitely, to do any munging on samples
> even if it is as simple as byteswap. It's the role of a userland
> based process to do mixing & format conversion. I hope alsa will
> finally provide something around those lines.

I don't know that much about ALSA.  Are you basically saying that all
audio apps should use a common userland library interface that handles
all the gory details of audio reformatting, so that the apps themselves
can be blithely ignorant of what's going on under the covers.  If so,
I could agree with that.  I just want a common interface, so every audio
app doesn't have to reinvent the wheel, and all the users don't have to
be bit by the same kinds of bugs over and over again.

I understand that ALSA is now available for PPC.  I'll have to take a
closer look at it when I get a chance.  When do you think ALSA will be
an integral part of the stable kernel?

						-Bill

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

Re: dmasound audio patch

[jeffk]

On Mon, 8 Apr 2002, Bill Fink wrote:

>
>
> I don't know that much about ALSA.  Are you basically saying that all
> audio apps should use a common userland library interface that handles
> all the gory details of audio reformatting, so that the apps themselves
> can be blithely ignorant of what's going on under the covers.  If so,
> I could agree with that.  I just want a common interface, so every audio
> app doesn't have to reinvent the wheel, and all the users don't have to
> be bit by the same kinds of bugs over and over again.
>
> I understand that ALSA is now available for PPC.  I'll have to take a
> closer look at it when I get a chance.  When do you think ALSA will be
> an integral part of the stable kernel?
>
>

I have to say that I have been very disappointed with ALSA in
general.  Documentation has been non existant, man pages completely
incorrect, buggy programs and libraries with no indication anywhere of
what is known to work and what is known not to work.  Maybe it has changed
in the last 6 months? Don't hold your breath.

BUT if there really is progress on the ALSA documentation it would be
nicer to have than the current sorry state of affairs of sound under
linux.

Jeff


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

Re: dmasound audio patch

[Ethan Benson]

On Mon, Apr 08, 2002 at 09:52:00PM -0400, Bill Fink wrote:
> I understand that ALSA is now available for PPC.  I'll have to take a
> closer look at it when I get a chance.  When do you think ALSA will be
> an integral part of the stable kernel?

when 2.5 becomes the next stable kernel (2.6 or 3.0).

--
Ethan Benson
http://www.alaska.net/~erbenson/

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

Re: dmasound audio patch

[Bill Fink]

On Mon, 8 Apr 2002, Ethan Benson wrote:

> On Mon, Apr 08, 2002 at 09:52:00PM -0400, Bill Fink wrote:
> > I understand that ALSA is now available for PPC. I'll have to take a
> > closer look at it when I get a chance. When do you think ALSA will be
> > an integral part of the stable kernel?
>
> when 2.5 becomes the next stable kernel (2.6 or 3.0).

I was afraid that was what someone would say.  :-)

				-Bill

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