Right now I'm looking into why SNDCTL_DSP_SETFMT is failing on 2.2.19
sparc. I've been trying to get ESD to work on my SS20 box so I can play
music.
The situation is that the ioctl() is failing with -EINVAL for a perfectly
valid argument.
Here's the strace output from running ESD (snipped for brevity)
open("/dev/dsp", O_WRONLY) = 3
ioctl(3, 0x6004500a, 0xefffe944) = 0
write(1, "DEBUG: 60045005\n", 16DEBUG: 60045005) = 16
write(1, "DEBUG: 00000010\n", 16DEBUG: 00000010) = 16
ioctl(3, 0x60045005, 0xefffe944) = -1 EINVAL (Invalid argument)
The debug statements I put in ESD shows the right argument with the right
value is being passed by the ioctl() call. 0x00000010 is AFTM_S16_BE, by
the way.
I've had a look at audio.c in /drivers/sbus/audio (lines 1046 to 1144),
and everything looks correct, down to the parameters, so why is it
returning -EINVAL?
Weird. Any ideas?
--
Top posters will be automatically killfiled.
http://www.tahallah.demon.co.uk
From: Alex Buell <[email protected]>
Date: Wed, 31 Oct 2001 10:41:29 +0000 (GMT)
Weird. Any ideas?
step 1:
cp src/linux/include/linux/soundcard.h /usr/include/linux/soundcard.h
step 2:
recompile your apps
Franks a lot,
David S. Miller
[email protected]
On Wed, 31 Oct 2001, David S. Miller wrote:
> cp src/linux/include/linux/soundcard.h /usr/include/linux/soundcard.h
Unfortunately, these files are identical, which is why it is so strange!
--
Come the revolution, humourless gits'll be first up against the wall.
http://www.tahallah.demon.co.uk
From: Alex Buell <[email protected]>
Date: Wed, 31 Oct 2001 18:28:28 +0000 (GMT)
On Wed, 31 Oct 2001, David S. Miller wrote:
> cp src/linux/include/linux/soundcard.h /usr/include/linux/soundcard.h
Unfortunately, these files are identical, which is why it is so strange!
I'm pretty sure the ioctl numbers are wrong, and that is what
is causing the problem.
Print out from your app the ioctl number it uses (you've done
this already) and have the kernel do similar. If they are different
you know that at least I was on the right track.
It's easy to figure out some value in the kernel without even
rebooting, just add to like some source file:
int foo = IOCTL_VALUE_I_WANT;
Then do "make drivers/sbus/audio/whatever.s"
and look at the assembler file for the value it
ended up using :-)
Franks a lot,
David S. Miller
[email protected]
On Wed, 31 Oct 2001, David S. Miller wrote:
> I'm pretty sure the ioctl numbers are wrong, and that is what is
> causing the problem.
No, the ioctl numbers are correct, it's ESD that's fscked.
/* set the sound driver audio format for playback */
#if defined(__powerpc__)
value = test = ( (esd_audio_format & ESD_MASK_BITS) == ESD_BITS16 )
? /* 16 bit */ AFMT_S16_NE : /* 8 bit */ AFMT_U8;
#else /* #if !defined(__powerpc__) */
value = test = ( (esd_audio_format & ESD_MASK_BITS) == ESD_BITS16 )
? /* 16 bit */ AFMT_S16_LE : /* 8 bit */ AFMT_U8;
#endif /* #if !defined(__powerpc__) */
<sarcasm>
This is such a lovely piece of code!
<sarcasm>
Anyway, I can fix it now by adding the appropriate AFMT_S16_BE statement
guarded by a #ifdef but this sucks. Thanks to Peter Jones who spotted this
one.
--
Come the revolution, humourless gits'll be first up against the wall.
http://www.tahallah.demon.co.uk
Alex Buell writes:
> No, the ioctl numbers are correct, it's ESD that's fscked.
>
> /* set the sound driver audio format for playback */
> #if defined(__powerpc__)
> value = test = ( (esd_audio_format & ESD_MASK_BITS) == ESD_BITS16 )
> ? /* 16 bit */ AFMT_S16_NE : /* 8 bit */ AFMT_U8;
> #else /* #if !defined(__powerpc__) */
> value = test = ( (esd_audio_format & ESD_MASK_BITS) == ESD_BITS16 )
> ? /* 16 bit */ AFMT_S16_LE : /* 8 bit */ AFMT_U8;
> #endif /* #if !defined(__powerpc__) */
>
> <sarcasm>
> This is such a lovely piece of code!
> <sarcasm>
Indeed...
> Anyway, I can fix it now by adding the appropriate AFMT_S16_BE statement
> guarded by a #ifdef but this sucks. Thanks to Peter Jones who spotted this
> one.
Why can't you just use AFMT_S16_NE on all platforms? That is supposed
to be equal to AFMT_S16_BE on big-endian platforms and to AFMT_S16_LE
on little-endian platforms. NE == native endian.
Paul.
On Thu, 1 Nov 2001, Paul Mackerras wrote:
> > Anyway, I can fix it now by adding the appropriate AFMT_S16_BE statement
> > guarded by a #ifdef but this sucks. Thanks to Peter Jones who spotted this
> > one.
>
> Why can't you just use AFMT_S16_NE on all platforms? That is supposed
> to be equal to AFMT_S16_BE on big-endian platforms and to AFMT_S16_LE
> on little-endian platforms. NE == native endian.
Ah, is that what it does. OK, I'll carefully suggest to the authors of ESD
(preferably with a blunt trauma instrument) using AFMT_S16_NE. Thanks.
--
Come the revolution, humourless gits'll be first up against the wall.
http://www.tahallah.demon.co.uk
On Thu, 1 Nov 2001, Alex Buell wrote:
> On Thu, 1 Nov 2001, Paul Mackerras wrote:
>
> > > Anyway, I can fix it now by adding the appropriate AFMT_S16_BE statement
> > > guarded by a #ifdef but this sucks. Thanks to Peter Jones who spotted this
> > > one.
> >
> > Why can't you just use AFMT_S16_NE on all platforms? That is supposed
> > to be equal to AFMT_S16_BE on big-endian platforms and to AFMT_S16_LE
> > on little-endian platforms. NE == native endian.
>
> Ah, is that what it does. OK, I'll carefully suggest to the authors of ESD
> (preferably with a blunt trauma instrument) using AFMT_S16_NE. Thanks.
It should probably be mentioned that you're using a really old version of
ESD, and that they've at least made it so that you'll get the right one
for any BE machine. NE is still the better answer though -- now their
configure script figures out BE/LE, and it'll build wrong if you're
crosscompiling.
--
Peter
"Don't everyone thank me at once!"
-- Solo
On Thu, 1 Nov 2001, Peter Jones wrote:
> > Ah, is that what it does. OK, I'll carefully suggest to the authors of ESD
> > (preferably with a blunt trauma instrument) using AFMT_S16_NE. Thanks.
> It should probably be mentioned that you're using a really old version
> of ESD, and that they've at least made it so that you'll get the right
> one for any BE machine. NE is still the better answer though -- now
> their configure script figures out BE/LE, and it'll build wrong if
> you're crosscompiling.
But this version I'm using is esound-2.2.8, which came from http://www.gnome.org!
I suppose I'll have to grab it from their CVS server.
--
Come the revolution, humourless gits'll be first up against the wall.
http://www.tahallah.demon.co.uk
On Thu, 1 Nov 2001, Alex Buell wrote:
> On Thu, 1 Nov 2001, Peter Jones wrote:
>
> > > Ah, is that what it does. OK, I'll carefully suggest to the authors of ESD
> > > (preferably with a blunt trauma instrument) using AFMT_S16_NE. Thanks.
>
> > It should probably be mentioned that you're using a really old version
> > of ESD, and that they've at least made it so that you'll get the right
> > one for any BE machine. NE is still the better answer though -- now
> > their configure script figures out BE/LE, and it'll build wrong if
> > you're crosscompiling.
>
> But this version I'm using is esound-2.2.8, which came from http://www.gnome.org!
> I suppose I'll have to grab it from their CVS server.
Oh, I'm sorry. You said "2.8" last time and I assumed you meant 0.2.8.
How interesting...
In any event, the answer is "use _NE", I think.
--
Peter
"We all enter this world in the same way: naked; screaming; soaked in
blood. But if you live your life right, that kind of thing doesn't have
to stop there."
-- Dana Gould
On Thu, 1 Nov 2001, Peter Jones wrote:
> Oh, I'm sorry. You said "2.8" last time and I assumed you meant
> 0.2.8. How interesting...
No, you're right, it's 0.2.8. Slip of the fingers..
> In any event, the answer is "use _NE", I think.
Yep. Thanks.
--
Come the revolution, humourless gits'll be first up against the wall.
http://www.tahallah.demon.co.uk