esound for PPC

esound for PPC

[Eric Dorland]

With some of the talk changing some of sound driver code, is anyone working
on esound for the PPC. It seems some progress has been made with 0.2.12,
which manages to play some wav files on my machine (G3/266 DT), but plays
garbage for others. Has anyone else seen this problem, or have gotten esound
working properly? 

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

Re: esound for PPC

[Elliot Lee]

On Sat, 2 Oct 1999, Eric Dorland wrote:

> With some of the talk changing some of sound driver code, is anyone
> working on esound for the PPC. It seems some progress has been made
> with 0.2.12, which manages to play some wav files on my machine
> (G3/266 DT), but plays garbage for others. Has anyone else seen this
> problem, or have gotten esound working properly?

Could you check if there is a correlation between the bit depth of the
sound file and the playing-of-garbage-noises? This problem sounds like an
audiofile bug.

Also, if people would please try out GNOME 1.0.50 this weekend and find
any PPC-specific problems ASAP, it'd be much appreciated.
-- Elliot					http://developer.gnome.org/
The first thing a programmer needs to admit is that any program is by far
more complex than his own mind. Thats why he partitions it into neat
pieces and avoids complexity.


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

Re: esound for PPC

[Eric Dorland]

On Sun, Oct 03, 1999 at 12:03:24AM -0400, Elliot Lee wrote:
> 
> On Sat, 2 Oct 1999, Eric Dorland wrote:
> 
> > With some of the talk changing some of sound driver code, is anyone
> > working on esound for the PPC. It seems some progress has been made
> > with 0.2.12, which manages to play some wav files on my machine
> > (G3/266 DT), but plays garbage for others. Has anyone else seen this
> > problem, or have gotten esound working properly?
> 
> Could you check if there is a correlation between the bit depth of the
> sound file and the playing-of-garbage-noises? This problem sounds like an
> audiofile bug.

It appears you're right. All the sounds that have trouble playing are 16bit
44kHz wavs. The weird thing is that if I start esd and use esdplay, all the
sounds play properly. However the 16bit sounds don't appear to be going
through esd because I don't get my prompt back until the sound is done
playing, while the 8bit sounds are played asynchronously.

> Also, if people would please try out GNOME 1.0.50 this weekend and find
> any PPC-specific problems ASAP, it'd be much appreciated.

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

Re: esound for PPC

[Tom Rini]

On Sun, 3 Oct 1999, Eric Dorland wrote:

> 
> On Sun, Oct 03, 1999 at 12:03:24AM -0400, Elliot Lee wrote:
> > 
> > On Sat, 2 Oct 1999, Eric Dorland wrote:
> > 
> > > With some of the talk changing some of sound driver code, is anyone
> > > working on esound for the PPC. It seems some progress has been made
> > > with 0.2.12, which manages to play some wav files on my machine
> > > (G3/266 DT), but plays garbage for others. Has anyone else seen this
> > > problem, or have gotten esound working properly?
> > 
> > Could you check if there is a correlation between the bit depth of the
> > sound file and the playing-of-garbage-noises? This problem sounds like an
> > audiofile bug.
> 
> It appears you're right. All the sounds that have trouble playing are 16bit
> 44kHz wavs. The weird thing is that if I start esd and use esdplay, all the
> sounds play properly. However the 16bit sounds don't appear to be going
> through esd because I don't get my prompt back until the sound is done
> playing, while the 8bit sounds are played asynchronously.

What happens is either audiofile or esound is doing byte swapping it
doesn't need to.

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


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

Re: esound for PPC

[Elliot Lee]

On Sun, 3 Oct 1999, Tom Rini wrote:

> > It appears you're right. All the sounds that have trouble playing are 16bit
> > 44kHz wavs. The weird thing is that if I start esd and use esdplay, all the
> > sounds play properly. However the 16bit sounds don't appear to be going
> > through esd because I don't get my prompt back until the sound is done
> > playing, while the 8bit sounds are played asynchronously.

This may just be because the 16bit sound files are bigger...

> What happens is either audiofile or esound is doing byte swapping it
> doesn't need to.

I think I heard somewhere that the PPC /dev/dsp uses little endian format,
while Sparc uses its native (big) endianness.

If someone could give me a table of what endianness the sound devices on
various platforms expect, I could make an esound-0.2.15 that fixes it
(after having you all test it :).

-- Elliot					http://developer.gnome.org/
The first thing a programmer needs to admit is that any program is by far
more complex than his own mind. Thats why he partitions it into neat
pieces and avoids complexity.


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

Re: esound for PPC

[Geert Uytterhoeven]

On Sun, 3 Oct 1999, Elliot Lee wrote:
> On Sun, 3 Oct 1999, Tom Rini wrote:
> > > It appears you're right. All the sounds that have trouble playing are 16bit
> > > 44kHz wavs. The weird thing is that if I start esd and use esdplay, all the
> > > sounds play properly. However the 16bit sounds don't appear to be going
> > > through esd because I don't get my prompt back until the sound is done
> > > playing, while the 8bit sounds are played asynchronously.
> 
> This may just be because the 16bit sound files are bigger...
> 
> > What happens is either audiofile or esound is doing byte swapping it
> > doesn't need to.
> 
> I think I heard somewhere that the PPC /dev/dsp uses little endian format,
> while Sparc uses its native (big) endianness.
> 
> If someone could give me a table of what endianness the sound devices on
> various platforms expect, I could make an esound-0.2.15 that fixes it
> (after having you all test it :).

There are different sound format codes for little and big endian 16 bit sound.
Look at the sound headers.

Greetings,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


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

Re: esound for PPC

[Elliot Lee]

On Mon, 4 Oct 1999, Geert Uytterhoeven wrote:

> There are different sound format codes for little and big endian 16
> bit sound. Look at the sound headers.

That isn't the problem here. Apparently someone put a bad hack into the
PPC sound driver that makes it default to little endian instead of big
endian format, and esound is expecting that "native endian" on the sound
device is "big endian", not "little endian".

-- Elliot					http://developer.gnome.org/
The first thing a programmer needs to admit is that any program is by far
more complex than his own mind. Thats why he partitions it into neat
pieces and avoids complexity.


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

Re: esound for PPC

[Benjamin Herrenschmidt]

On Mon, Oct 4, 1999, Elliot Lee <sopwith@redhat.com> wrote:

>That isn't the problem here. Apparently someone put a bad hack into the
>PPC sound driver that makes it default to little endian instead of big
>endian format, and esound is expecting that "native endian" on the sound
>device is "big endian", not "little endian".

I may be wrong, but to me, this looks like a bug in esound. The driver
seems capable of telling the application about it's current format and
can be told to change it. If esound does assumptions about the default
format instead of querying the driver, then esound is broken. (Also the
driver may have been switched to another format by an application before
esound takes control anyway. I don't remember which of /dev/audio or
/dev/dsp will keep the current setting so this may not be an issue).

I agree that the driver lacks a call to query about the native endian, so
if you really want to, you can add code to esound to force-switch to big
endian on PowerMac, but at least, it should be fixed to not rely on a
supposed default setting.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: esound for PPC

[Elliot Lee]

On Tue, 5 Oct 1999, Benjamin Herrenschmidt wrote:

> I may be wrong, but to me, this looks like a bug in esound. The driver
> seems capable of telling the application about it's current format and
> can be told to change it. If esound does assumptions about the default
> format instead of querying the driver, then esound is broken. (Also
> the driver may have been switched to another format by an application
> before esound takes control anyway. I don't remember which of
> /dev/audio or /dev/dsp will keep the current setting so this may not
> be an issue).
> 
> I agree that the driver lacks a call to query about the native endian,
> so if you really want to, you can add code to esound to force-switch
> to big endian on PowerMac, but at least, it should be fixed to not
> rely on a supposed default setting.

In ftp://people.redhat.com/sopwith/esound-0.2.15.tar.gz (not a final
release), it explicitly sets big-endian mode on big-endian machines, so
things should work a bit better. There is also a related bug in the sound
file playback code fixed, that should help davem's "esdplay plays garbage"
problems. Please try this out and let me know.

-- Elliot					http://developer.gnome.org/
The first thing a programmer needs to admit is that any program is by far
more complex than his own mind. Thats why he partitions it into neat
pieces and avoids complexity.


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

Re: esound for PPC

[Eric Dorland]

On Tue, Oct 05, 1999 at 07:36:19AM -0400, Elliot Lee wrote:
> In ftp://people.redhat.com/sopwith/esound-0.2.15.tar.gz (not a final
> release), it explicitly sets big-endian mode on big-endian machines, so
> things should work a bit better. There is also a related bug in the sound
> file playback code fixed, that should help davem's "esdplay plays garbage"
> problems. Please try this out and let me know.

Unfortunately, under my machine (G3/266 DT) this version works even more
poorly than the one I was using before. The startup beeps are now more like
startup hisses, and wavs (whether 8-bit or 16) sound like a bunch of
hissing. To compile it I just did a vanilla ./configure; make; make install
which seemed to be the right thing to do.

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

Re: esound for PPC

[Eric Dorland]

On Tue, Oct 05, 1999 at 08:40:16PM -0400, Eric Dorland wrote:
> 
> On Tue, Oct 05, 1999 at 07:36:19AM -0400, Elliot Lee wrote:
> > In ftp://people.redhat.com/sopwith/esound-0.2.15.tar.gz (not a final
> > release), it explicitly sets big-endian mode on big-endian machines, so
> > things should work a bit better. There is also a related bug in the sound
> > file playback code fixed, that should help davem's "esdplay plays garbage"
> > problems. Please try this out and let me know.
> 
> Unfortunately, under my machine (G3/266 DT) this version works even more
> poorly than the one I was using before. The startup beeps are now more like
> startup hisses, and wavs (whether 8-bit or 16) sound like a bunch of
> hissing. To compile it I just did a vanilla ./configure; make; make install
> which seemed to be the right thing to do.

Well, I've been following the development of enlightenment (0.16 just been
released, BTW) and they've got a fix in their sound code which fixes sound
playing (in E anyway). The fix has more to do with libaudiofile than esd. On
lines 80-84 in sound.c (the LoadWav function) we find:

#ifdef WORDS_BIGENDIAN
      afSetVirtualByteOrder(in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_BIGENDIAN);
   #else
      afSetVirtualByteOrder(in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_LITTLEENDIAN);
#endif

I don't know audiofile particularly well, but its obvious this is telling
audiofile to output the file in as big-endian for the later afReadFrames
statement. This means any application that's using audiofile should have
this line in them, and audiofile should compile by default with the Virtual
Byte Order set to big-endian on big-endian machines (the current version may
do this, I haven't looked at the code). GNOME's sound code doesn't have this
hack, so I'm going to send them a patch, hopefully in time for 1.0.50.

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

Re: esound for PPC

[Eric Dorland]

On Mon, Oct 11, 1999 at 02:06:49AM -0400, Eric Dorland wrote:
> Well, I've been following the development of enlightenment (0.16 just been
> released, BTW) and they've got a fix in their sound code which fixes sound
> playing (in E anyway). The fix has more to do with libaudiofile than esd. On
> lines 80-84 in sound.c (the LoadWav function) we find:
> 
> #ifdef WORDS_BIGENDIAN
>       afSetVirtualByteOrder(in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_BIGENDIAN);
>    #else
>       afSetVirtualByteOrder(in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_LITTLEENDIAN);
> #endif
> 
> I don't know audiofile particularly well, but its obvious this is telling
> audiofile to output the file in as big-endian for the later afReadFrames
> statement. This means any application that's using audiofile should have
> this line in them, and audiofile should compile by default with the Virtual
> Byte Order set to big-endian on big-endian machines (the current version may
> do this, I haven't looked at the code). GNOME's sound code doesn't have this
> hack, so I'm going to send them a patch, hopefully in time for 1.0.50.

I little browsing of the code does show that libaudiofile sets the virtual
byte order, by default, to the correct setting for the current architecture.
And looking at gnome-libs, up in till last week, the sound code was
explicitly setting the virtual byte order to little-endian. Thankfully now
its fixed, so the next build of GNOME should have working sound.

It appears I spoke to soon about sound working perfectly. Whenever esd plays
a 16bit wav file, the sound plays at about half speed. Ugg. At least its not
static anymore. I'm going to see if I can track down why this is happening
(maybe its some on-the-fly endianess swaping slowing it down), but I don't
know sound code all that well, so anyone that does, please lend a hand.

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

Re: esound for PPC

[Tom Rini]

On Mon, 11 Oct 1999, Eric Dorland wrote:

> It appears I spoke to soon about sound working perfectly. Whenever esd plays
> a 16bit wav file, the sound plays at about half speed. Ugg. At least its not
> static anymore. I'm going to see if I can track down why this is happening
> (maybe its some on-the-fly endianess swaping slowing it down), but I don't
> know sound code all that well, so anyone that does, please lend a hand.

Elliot has the old set of patches ported up to 0.2.15, and hopefully will
be in 0.2.16 :)

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


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

Re: esound for PPC

[Ryan Nielsen]

Tom Rini wrote:
> 
> On Mon, 11 Oct 1999, Eric Dorland wrote:
> 
> > It appears I spoke to soon about sound working perfectly. Whenever esd plays
> > a 16bit wav file, the sound plays at about half speed. Ugg. At least its not
> > static anymore. I'm going to see if I can track down why this is happening
> > (maybe its some on-the-fly endianess swaping slowing it down), but I don't
> > know sound code all that well, so anyone that does, please lend a hand.
> 
> Elliot has the old set of patches ported up to 0.2.15, and hopefully will
> be in 0.2.16 :)

Does this fix the problem Eric wrote about ?
Þere is a bug in dmasound.c that causes sound to be played at 22050 Hz
instead of (usually) 44100 Hz if a beep (from awacs_mksound) is played.

I thought this should happen only if the process is suspended, but I made
beeps with the console while mpg123 was playing.

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

Re: esound for PPC

[Eric Dorland]

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

On Mon, Oct 11, 1999 at 01:09:12PM -0700, Tom Rini wrote:
> 
> On Mon, 11 Oct 1999, Eric Dorland wrote:
> 
> > It appears I spoke to soon about sound working perfectly. Whenever esd plays
> > a 16bit wav file, the sound plays at about half speed. Ugg. At least its not
> > static anymore. I'm going to see if I can track down why this is happening
> > (maybe its some on-the-fly endianess swaping slowing it down), but I don't
> > know sound code all that well, so anyone that does, please lend a hand.
> 
> Elliot has the old set of patches ported up to 0.2.15, and hopefully will
> be in 0.2.16 :)

Which old set of patches? I've tried Elliot's 0.2.15 and it doesn't fix 
the playing of 16bit sounds. BTW, you need a patch to be able to compile 
Elliot's 0.2.15. It seems the configure file assumes that a ppc linux is 
MkLinux, and uses its driver instead of OSS. It appears its MkLinux that has 
the little-endian sound driver, not linuxppc. Anyway the attached patch 
changes removes the MkLinux testing (I don't know how to tell the
difference), and just uses OSS.

Also, passing the -b switch forces esd to use 8bit samples, so even the
16bit sounds play properly (albeit at 8bits). Unfortunately, for some reason
esd reverts to 16bit after a while, and 16bit sounds play slowly once again.

Please, anyone who knows anything about esd or sound programming in general,
mail me and help me fix this :)

[-- Attachment #2: esound-0.2.15.ppc.patch --]
[-- Type: text/plain, Size: 2873 bytes --]

--- configure.old	Mon Oct 11 16:14:40 1999
+++ configure	Mon Oct 11 16:14:46 1999
@@ -3073,19 +3073,12 @@
       test "${ac_cv_header_soundcard_h}" = "yes" || \
       test "${ac_cv_header_machine_soundcard_h}" = "yes"; then
 
-            if test "${host_cpu}" = "powerpc"; then
-        found_sound=yes
-        cat >> confdefs.h <<\EOF
-#define DRIVER_MKLINUX 1
-EOF
-
-      else
-        found_sound=yes
-        cat >> confdefs.h <<\EOF
+      found_sound=yes
+      cat >> confdefs.h <<\EOF
 #define DRIVER_OSS 1
 EOF
 
-      fi
+  
    fi
 
    if test "${ac_cv_header_sys_audio_h}" = "yes"; then
--- configure.in.old	Mon Oct 11 16:07:55 1999
+++ configure.in	Mon Oct 11 16:21:49 1999
@@ -116,14 +116,9 @@
       test "${ac_cv_header_soundcard_h}" = "yes" || \
       test "${ac_cv_header_machine_soundcard_h}" = "yes"; then
 
-      dnl Platform mklinux/powerpc needs special care and feeding
-      if test "${host_cpu}" = "powerpc"; then
-        found_sound=yes
-        AC_DEFINE(DRIVER_MKLINUX)
-      else
-        found_sound=yes
-        AC_DEFINE(DRIVER_OSS)
-      fi
+      found_sound=yes
+      AC_DEFINE(DRIVER_OSS)
+     
    fi
 
    if test "${ac_cv_header_sys_audio_h}" = "yes"; then
--- esdfile.c.old	Mon Oct 11 16:16:07 1999
+++ esdfile.c	Mon Oct 11 16:21:48 1999
@@ -157,8 +157,12 @@
     length = afGetTrackBytes( in_file, AF_DEFAULT_TRACK );
     afGetSampleFormat( in_file, AF_DEFAULT_TRACK, &in_format, &in_width );
 
-    /* TODO: should this be set to the native endian order of the playing machine? */
-    afSetVirtualByteOrder( in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_LITTLEENDIAN );
+     /* TODO: should this be set to the native endian order of the playing machine? */
+#if defined(__powerpc__)
+    afSetVirtualByteOrder( in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_BIGENDIAN );
+#else /* #if !defined(__powerpc__) */
+     afSetVirtualByteOrder( in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_LITTLEENDIAN );
+#endif
 
     /*  printf ("frames: %i channels: %i rate: %f format: %i width: %i\n",
      *	        frame_count, in_channels, in_rate, in_format, in_width);
--- esdplay.c.old	Mon Oct 11 16:16:24 1999
+++ esdplay.c	Mon Oct 11 16:21:44 1999
@@ -51,8 +51,13 @@
   in_rate = afGetRate (in_file, AF_DEFAULT_TRACK);
   afGetSampleFormat (in_file, AF_DEFAULT_TRACK, &in_format, &in_width);
 
-  afSetVirtualByteOrder (in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_LITTLEENDIAN);
-
+/* TODO: should this be set to the native endian order of the playing machine? */
+#if defined(__powerpc__)
+    afSetVirtualByteOrder( in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_BIGENDIAN );
+#else /* #if !defined(__powerpc__) */
+     afSetVirtualByteOrder( in_file, AF_DEFAULT_TRACK, AF_BYTEORDER_LITTLEENDIAN );
+#endif
+  
   printf ("frames: %i channels: %i rate: %f format: %i width: %i\n",
     frame_count, in_channels, in_rate, in_format, in_width);
 

Re: esound for PPC

[Tom Rini]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1101 bytes --]


On Mon, 11 Oct 1999, Ryan Nielsen wrote:

> Tom Rini wrote:
> > 
> > On Mon, 11 Oct 1999, Eric Dorland wrote:
> > 
> > > It appears I spoke to soon about sound working perfectly. Whenever esd plays
> > > a 16bit wav file, the sound plays at about half speed. Ugg. At least its not
> > > static anymore. I'm going to see if I can track down why this is happening
> > > (maybe its some on-the-fly endianess swaping slowing it down), but I don't
> > > know sound code all that well, so anyone that does, please lend a hand.
> > 
> > Elliot has the old set of patches ported up to 0.2.15, and hopefully will
> > be in 0.2.16 :)
> 
> Does this fix the problem Eric wrote about ?
> Þere is a bug in dmasound.c that causes sound to be played at 22050 Hz
> instead of (usually) 44100 Hz if a beep (from awacs_mksound) is played.

It only fixed problems that're really esound's fault (ie the static
stuff).  Whats broken in 0.2.14 is still broken (and dmasound is crap
anyhow :))

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


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

Re: esound for PPC

[Tom Rini]

On Mon, 11 Oct 1999, Eric Dorland wrote:

> On Mon, Oct 11, 1999 at 01:09:12PM -0700, Tom Rini wrote:
> > 
> > On Mon, 11 Oct 1999, Eric Dorland wrote:
> > 
> > > It appears I spoke to soon about sound working perfectly. Whenever esd plays
> > > a 16bit wav file, the sound plays at about half speed. Ugg. At least its not
> > > static anymore. I'm going to see if I can track down why this is happening
> > > (maybe its some on-the-fly endianess swaping slowing it down), but I don't
> > > know sound code all that well, so anyone that does, please lend a hand.
> > 
> > Elliot has the old set of patches ported up to 0.2.15, and hopefully will
> > be in 0.2.16 :)
> 
> Which old set of patches? I've tried Elliot's 0.2.15 and it doesn't fix 
> the playing of 16bit sounds. BTW, you need a patch to be able to compile 
> Elliot's 0.2.15. It seems the configure file assumes that a ppc linux is 
> MkLinux, and uses its driver instead of OSS. It appears its MkLinux that has 
> the little-endian sound driver, not linuxppc. Anyway the attached patch 
> changes removes the MkLinux testing (I don't know how to tell the
> difference), and just uses OSS.

The patches which exist in a copy of 0.2.14, hence any working esound.
They did not make it into 0.2.15, but will hopefully be in 0.2.16.  It
does tell from MkL & Linux/PPC, and it also makes everything work "ok"
again.

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


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

Re: esound for PPC

[Eric Dorland]

On Mon, Oct 11, 1999 at 08:20:26PM -0700, Tom Rini wrote:
> On Mon, 11 Oct 1999, Eric Dorland wrote:
> 
> > On Mon, Oct 11, 1999 at 01:09:12PM -0700, Tom Rini wrote:
> > > 
> > > On Mon, 11 Oct 1999, Eric Dorland wrote:
> > > 
> > > > It appears I spoke to soon about sound working perfectly. Whenever esd plays
> > > > a 16bit wav file, the sound plays at about half speed. Ugg. At least its not
> > > > static anymore. I'm going to see if I can track down why this is happening
> > > > (maybe its some on-the-fly endianess swaping slowing it down), but I don't
> > > > know sound code all that well, so anyone that does, please lend a hand.
> > > 
> > > Elliot has the old set of patches ported up to 0.2.15, and hopefully will
> > > be in 0.2.16 :)
> > 
> > Which old set of patches? I've tried Elliot's 0.2.15 and it doesn't fix 
> > the playing of 16bit sounds. BTW, you need a patch to be able to compile 
> > Elliot's 0.2.15. It seems the configure file assumes that a ppc linux is 
> > MkLinux, and uses its driver instead of OSS. It appears its MkLinux that has 
> > the little-endian sound driver, not linuxppc. Anyway the attached patch 
> > changes removes the MkLinux testing (I don't know how to tell the
> > difference), and just uses OSS.
> 
> The patches which exist in a copy of 0.2.14, hence any working esound.
> They did not make it into 0.2.15, but will hopefully be in 0.2.16.  It
> does tell from MkL & Linux/PPC, and it also makes everything work "ok"
> again.

Which copy of 0.2.14? Where is it? I'd love to try them out :)

-- 

Eric Dorland
dorland@lords.com

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

Re: esound for PPC

[Ryan Nielsen]

Eric Dorland wrote:
> On Sat, Oct 23, 1999 at 08:33:34PM -0700, Ryan Nielsen wrote:
> > Eric Dorland wrote:
> > > I finally had the chance to recompile my kernel and try your patch, which so
> > > far is working flawlessly. The only bug i've noticed is that regular beeps
> > > sound slightly clipped. You should post the patch to the list if you haven't
> > > already done so :)
> > 
> > does it fix the esound problem ?
> 
> It does indeed.
>  
> > I posted it to the list before but noone replied except for one saying it broke
> > a workaround for a bug, search the dev list at lists.linuxppc.org for 'dmasound bug'.
> 
> Yes, there is a bit of a hissing, but I find the hissing is only noticable
> at really high volumes, on my G3, so it doesn't bother me at all.

can someone fix that hissing problem and get this patch into the kernel ?
diff -u -r1.41.2.2 dmasound.c
--- dmasound.c	1999/08/16 01:58:47	1.41.2.2
+++ dmasound.c	1999/10/25 22:15:23
@@ -3169,9 +3169,9 @@
 	if (beep_playing) {
 		/* sound takes precedence over beeps */
 		out_le32(&awacs_txdma->control, (RUN|PAUSE|FLUSH|WAKE) << 16);
-		out_le32(&awacs->control,
-			 (in_le32(&awacs->control) & ~0x1f00)
-			 || (awacs_rate_index << 8));
+		out_le32(&awacs->control, MASK_IEPC
+			 | (awacs_rate_index << 8) | 0x11
+			 | (awacs_revision < AWACS_BURGUNDY? MASK_IEE: 0));
 		out_le32(&awacs->byteswap, sound.hard.format != AFMT_S16_BE);
 		beep_playing = 0;
 	}
@@ -3259,6 +3259,11 @@
 	save_flags(flags); cli();
 	if (beep_playing) {
 		st_le16(&beep_dbdma_cmd->command, DBDMA_STOP);
+		out_le32(&awacs_txdma->control, (RUN|PAUSE|FLUSH|WAKE) << 16);
+		out_le32(&awacs->control, MASK_IEPC
+			 | (awacs_rate_index << 8) | 0x11
+			 | (awacs_revision < AWACS_BURGUNDY? MASK_IEE: 0));
+		out_le32(&awacs->byteswap, sound.hard.format != AFMT_S16_BE);
 		beep_playing = 0;
 	}
 	restore_flags(flags);

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

recv programming problem...

[Morningstar]

	Okay I might be a moron and have been going about this all
 wrong, but I can't for the life of me figure out why this code acts
 the way it does. It's a simple client/server program using 
 send/recv.
	What happens is this. When files are larger than the send/recieve
 buffers. They are split up, sent, recieved, and closed just fine. When
 the file is less than the buffer size, the server sends everything just
 fine but the client hangs. I thought that the recv command reported
 everything up to the max its told to read. It seems to act like this
 when recieving the segmented files, just not the single buffer ones. 
 Here's the code snippets and output...

     do               	/*Server Code...ret_buffer =[4096]*/
	{nread = fread(ret_buffer, 1, sizeof(ret_buffer), local_file);
	send(fd, ret_buffer, nread,0); 
	cout<<nread<<endl;}    /*Outputs char sent for debug*/
      while(!feof(local_file));
      send(fd, 0,1,0);         /*Send signal to client it's done*/
      cout<<"File Done..."<<end;

     do    		/*Client Code...in_buffer is again 4096 */
	{  nread=recv(socketfd, in_buffer, sizeof(in_buffer), 0);
	   test=fwrite(in_buffer, 1, nread, local_file);	
	   cout<<nread<<":"<<endl;}   /*Outputs char in for debug */
      while(in_buffer[nread-1] != '\0');

	This Produces the following output...

		   Server                  Client
        /neotrin.jpg			/neotrin.jpg
	4096				4096
	4096				4096
	1345				1344
	File Done			File Done

	/client.cpp			/client.cpp
	2494				2494
	File Done...			(hangs...)

  The closest I've figured out to what's wrong is that the
 client is not recieving the second send signal(the termination one)
 because if I remove it, the larger files exhibit the same behavior.
 Yet why would it work on a segment of a file that is less than the
 buffer size and not a single file that is less than the buffer size.

  The tech specs of the machine are. Biege G3 333, LinuxR5 2.2.6-15 
 gcc version egcs-2.91.66  

  Sorry for the long post but this has me beating my head against a wall.
 I do apreaciate any input people can give. Cheers.	

						-Morningstar

		* We dance where angels fear to tread *

  	  * I seek a lover whose kiss is like an open wound *

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

Re: esound for PPC

[Dan Malek]

Ryan Nielsen wrote:


> can someone fix that hissing problem ......

I did that in the 2.3.xx kernel while adding the recording stuff.  At
the time the 2.2.x was "frozen" to updates so I didn't perform the same
updates in the 2.2.x tree.  I guess I can go back and do that, although
there has been lots of activity around this driver lately, including
threats of re-writes.

I have some updates as well, so how about everyone working on something
in this driver speak up and we coordinate this......


	-- Dan

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

Re: esound for PPC

[Elliot Lee]

On Mon, 11 Oct 1999, Eric Dorland wrote:

> Which old set of patches? I've tried Elliot's 0.2.15 and it doesn't fix 
> the playing of 16bit sounds. BTW, you need a patch to be able to compile 
> Elliot's 0.2.15. It seems the configure file assumes that a ppc linux is 
> MkLinux, and uses its driver instead of OSS. It appears its MkLinux that has 
> the little-endian sound driver, not linuxppc. Anyway the attached patch 
> changes removes the MkLinux testing (I don't know how to tell the
> difference), and just uses OSS.

I've applied the configure.in change (configure itself is a generated
file, along with Makefile.in etc., so sending patches to these is
pointless :)

I skipped the esdplay.c/esdfile.c ones because I had other solutions (such
as removing that code entirely.

If you ever see any code doing a 'setvirtualbyteorder', that line probably
should probably just be nixed altogether. There is only one place that
ever needs doing, and that is inside libesd.

Anyways, I have put up
ftp://people.redhat.com/sopwith/esound-0.2.16.tar.gz - this will probably
become the final thing if you and other people have no problems with it.
It is not yet final, so don't go sticking it into public download dirs or
anything. :)

You will also want to make sure you have gnome-libs 1.0.53 (from October
GNOME) or newer, since I know there was an endianness fix in the 1.0.40
series.

Thanks,
-- Elliot
Do not meddle in the affairs of dragons,
for you are crunchy and good with ketchup. 


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