Hello!
The Linux-sound list appears to be dead (I don't see my message in
http://www.kernelnotes.org/lnxlists/linux-sound/), so I'm sending to the
authors and the people discussing the problem on the linux-kernel mailing
list.
An additional problem is that opl3 cannot find the device unless I load
and unload the old driver (ymf_sb). Probably the new driver should put the
OPL3 interface to the legacy mode if it cannot handle it directly.
This confirms my point that you should not disable building both drivers
as modules at this stage.
Regards,
Pavel Roskin
---------- Forwarded message ----------
Date: Tue, 5 Dec 2000 19:26:34 -0500 (EST)
From: Pavel Roskin <[email protected]>
To: [email protected]
Subject: YMF PCI - thanks, glitches, patches
Hello!
The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:
Dec 5 18:07:11 fonzie kernel: ymfpci0: YMF740C at 0xf0000000 IRQ 10
Dec 5 18:07:11 fonzie kernel: ac97_codec: AC97 Audio codec, id:
0x4144:0x5303 (Unknown)
Thanks to everybody who made it!
Now about problems. Sometimes I get such messages in the log:
Dec 5 18:08:16 fonzie kernel: ymfpci: ioctl cmd 0x5401
Dec 5 18:08:50 fonzie last message repeated 9 times
While playing some sounds I'm getting
$ play spinout.wav
sox: Unable to set audio speed to 5512 (set to 8000)
$ file spinout.wav
spinout.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit,
mono 5512 Hz
This always happens for some sounds, and never happens for others. This
message doesn't appear with the old driver (ymf_sb). I'm attaching
spinout.wav.
The next problem is the configuration file, linux/drivers/sound/Config.in.
I'm sending you a patch that fixes the following problems:
1) The new driver does not depend (directly or indirectly) on the OSS
sound.o module, thus CONFIG_SOUND_YMFPCI should not depend on
CONFIG_SOUND_OSS.
2) CONFIG_SOUND_YMFPCI should depend on CONFIG_PCI. You cannot compile the
driver without PCI support.
3) Both drivers (native and legacy) should disable the other driver if
eigther of them is to be compiled into the kernel. However, it should be
possible to compile both drivers as modules. I did it so I can compare
them.
4) Don't forget about spaces in the description.
You may also want to add a dependency to CONFIG_EXPERIMENTAL for
CONFIG_SOUND_YMFPCI (not in my patch) if you feel that the driver is not
ready for everybody. Just writing (EXPERIMENTAL) doesn't disable the
question about the driver when CONFIG_EXPERIMENTAL is not set.
The patch also contains minimal descriptions for CONFIG_SOUND_YMPCI and
CONFIG_SOUND_YMFPCI. I hope somebody will add more stuff there.
By the way, I'm surprised why many drivers for PCI sound cards don't
depend on CONFIG_PCI.
Regards,
Pavel Roskin
_______________________
--- linux/Documentation/Configure.help Tue Dec 5 10:08:10 2000
+++ linux/Documentation/Configure.help Tue Dec 5 17:57:26 2000
@@ -14250,6 +14250,18 @@
If unsure, say Y.
+Yamaha PCI native mode support (EXPERIMENTAL)
+CONFIG_SOUND_YMFPCI
+ This is an experimental driver that uses Yamaha PCI sound cards in
+ the native mode. You may also want to try another driver,
+ "Yamaha PCI legacy mode support" under the OSS drivers.
+
+Yamaha PCI legacy mode support
+CONFIG_SOUND_YMPCI
+ This is a driver for Yamaha PCI sound cards that turns them
+ to the Sound Blaster compatible mode. You don't need to enable
+ Sound Blaster support to use it.
+
ACI mixer (miroPCM12/PCM20)
CONFIG_SOUND_ACI_MIXER
ACI (Audio Command Interface) is a protocol used to communicate with
--- linux/drivers/sound/Config.in Tue Dec 5 10:08:13 2000
+++ linux/drivers/sound/Config.in Tue Dec 5 17:59:30 2000
@@ -79,6 +79,9 @@
fi
dep_tristate ' VIA 82C686 Audio Codec' CONFIG_SOUND_VIA82CXXX $CONFIG_PCI
+if [ "$CONFIG_SOUND_YMPCI" != "y" ]; then
+ dep_tristate ' Yamaha PCI native mode support (EXPERIMENTAL)' CONFIG_SOUND_YMFPCI $CONFIG_SOUND $CONFIG_PCI
+fi
dep_tristate ' OSS sound modules' CONFIG_SOUND_OSS $CONFIG_SOUND
@@ -142,9 +145,8 @@
dep_tristate ' Yamaha FM synthesizer (YM3812/OPL-3) support' CONFIG_SOUND_YM3812 $CONFIG_SOUND_OSS
dep_tristate ' Yamaha OPL3-SA1 audio controller' CONFIG_SOUND_OPL3SA1 $CONFIG_SOUND_OSS
dep_tristate ' Yamaha OPL3-SA2, SA3, and SAx based PnP cards' CONFIG_SOUND_OPL3SA2 $CONFIG_SOUND_OSS
- dep_tristate ' Yamaha PCI legacy mode support' CONFIG_SOUND_YMPCI $CONFIG_SOUND_OSS $CONFIG_PCI
- if [ "$CONFIG_SOUND_YMPCI" = "n" ]; then
- dep_tristate 'Yamaha PCI native mode support (EXPERIMENTAL)' CONFIG_SOUND_YMFPCI $CONFIG_SOUND_OSS
+ if [ "$CONFIG_SOUND_YMFPCI" != "y" ]; then
+ dep_tristate ' Yamaha PCI legacy mode support' CONFIG_SOUND_YMPCI $CONFIG_SOUND_OSS $CONFIG_PCI
fi
dep_tristate ' 6850 UART support' CONFIG_SOUND_UART6850 $CONFIG_SOUND_OSS
_______________________
> Date: Wed, 6 Dec 2000 13:12:13 -0500 (EST)
> From: Pavel Roskin <[email protected]>
> cc: Jaroslav Kysela <[email protected]>, Pete Zaitcev <[email protected]>,
> <[email protected]>, <[email protected]>
> The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:
I did not have a chance to look at whatever is in 2.4, but from
reading Linus's e-mails I understand that Jaroslav made a new
port, which is probably unrelated to the stuff that I hastily
cooked up for 2.2 (I really wanted to play Doom on my new Sony).
I am sorry for the lack of communication.
I'll see what 2.2 does about 1) playing at 5512 Hz, 2) compiling
as modules together (non-modules are made to be exclusive),
3) compiling if CONFIG_PCI is not enabled, 4) has Configure.help
update.
I am not sure what to do about CONFIG_EXPERIMENTAL.
My current plan is to discard "(EXPERIMENTAL)" and forget
about it until the next case.
Ioctl 0x5401 is a mystery. I do not know what it is
(looks like SNDCTL_TMR_TIMEBASE without uppper bits).
Please send fewer attachements to the lists. Your sound fragment
is very useful, but I'd prefer to have it sent separately to me
upon a request (in uuencode :).
BTW, Legacy driver (ymf_sb) uses PC/DMA or whatever the name is,
which requires the north bridge support and, sometimes, additional
connections on the motherboard. This is not reflected in _any_
kernel documentation. I have spent numerous hours trying to make
it work on my laptop until I understood that even though my
chipset supports PC/DMA, necessary connections are missing.
At first glance, it looked as if IRQ does not come.
-- Pete
On Wed, 6 Dec 2000, Pete Zaitcev wrote:
> > Date: Wed, 6 Dec 2000 13:12:13 -0500 (EST)
> > From: Pavel Roskin <[email protected]>
> > cc: Jaroslav Kysela <[email protected]>, Pete Zaitcev <[email protected]>,
> > <[email protected]>, <[email protected]>
>
> > The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:
>
> I did not have a chance to look at whatever is in 2.4, but from
> reading Linus's e-mails I understand that Jaroslav made a new
> port, which is probably unrelated to the stuff that I hastily
> cooked up for 2.2 (I really wanted to play Doom on my new Sony).
:-)))
> I am sorry for the lack of communication.
Why sorry? Do you mean that the linux-sound list is not dead and you saw
my message there?
> I'll see what 2.2 does about 1) playing at 5512 Hz, 2) compiling
> as modules together (non-modules are made to be exclusive),
> 3) compiling if CONFIG_PCI is not enabled, 4) has Configure.help
> update.
>
> I am not sure what to do about CONFIG_EXPERIMENTAL.
> My current plan is to discard "(EXPERIMENTAL)" and forget
> about it until the next case.
But please note that opl3 is not enabled by the new driver, so people do
lose some functionality they used to have.
> Ioctl 0x5401 is a mystery. I do not know what it is
> (looks like SNDCTL_TMR_TIMEBASE without uppper bits).
It is caused by an attempt to play at 5512 Hz. In fact, this time (I've
upgraded to test12-pre6 in the meantime) it hung very badly, so that even
"kill -KILL" doesn't help:
3786 pts/3 D 0:00 sox spinout.wav -t ossdsp /dev/dsp
sox-12.16-7, RedHat 6.2. The same with sox-12.17.1. The later uses
SNDCTL_DSP_SPEED to set the rate, but still the message about ioctl 0x5401
appears in the log.
> Please send fewer attachements to the lists. Your sound fragment
> is very useful, but I'd prefer to have it sent separately to me
> upon a request (in uuencode :).
Sorry :-(
> BTW, Legacy driver (ymf_sb) uses PC/DMA or whatever the name is,
> which requires the north bridge support and, sometimes, additional
> connections on the motherboard. This is not reflected in _any_
> kernel documentation. I have spent numerous hours trying to make
> it work on my laptop until I understood that even though my
> chipset supports PC/DMA, necessary connections are missing.
> At first glance, it looked as if IRQ does not come.
Maybe it explains why I'll have to reboot now to kill that "sox" :-/
Regards,
Pavel Roskin
> > Ioctl 0x5401 is a mystery. I do not know what it is
> > (looks like SNDCTL_TMR_TIMEBASE without uppper bits).
>
> It is caused by an attempt to play at 5512 Hz. In fact, this time (I've
I was wrong. It happens for all sounds when sox calls
setvbuf (ft->fp,NULL,_IOFBF,sizeof(char)*BUFSIZ)
Ioctl 0x5401 is not a mystery. It's TCGETS (see
include/asm-i386/ioctls.h). Other drivers (sb_mixer.c) return -EINVAL
silently while ymfpci.c returns -ENOTTY and writes to the log.
> upgraded to test12-pre6 in the meantime) it hung very badly, so that even
> "kill -KILL" doesn't help:
This problem is also fixed by my patch.
_____________________
--- ymfpci.c Wed Dec 6 11:19:15 2000
+++ ymfpci.c Wed Dec 6 15:50:46 2000
@@ -1867,18 +1867,12 @@
case SNDCTL_DSP_SETSYNCRO:
case SOUND_PCM_WRITE_FILTER:
case SOUND_PCM_READ_FILTER:
- return -ENOTTY;
+ printk("ymfpci: ioctl cmd 0x%x\n not yet supported", cmd);
+ return -EINVAL;
default:
- /* P3 */ printk("ymfpci: ioctl cmd 0x%x\n", cmd);
- /*
- * Some programs mix up audio devices and ioctls
- * or perhaps they expect "universal" ioctls,
- * for instance we get SNDCTL_TMR_CONTINUE here.
- * XXX Is there sound_generic_ioctl() around?
- */
+ return -EINVAL;
}
- return -ENOTTY;
}
static int ymf_open(struct inode *inode, struct file *file)
_____________________
> Maybe it explains why I'll have to reboot now to kill that "sox" :-/
Nope :-)
Regards,
Pavel Roskin
> Date: Wed, 6 Dec 2000 15:00:38 -0500 (EST)
> From: Pavel Roskin <[email protected]>
> To: Pete Zaitcev <[email protected]>
> Subject: Re: YMF PCI - thanks, glitches, patches (fwd)
> > > Date: Wed, 6 Dec 2000 13:12:13 -0500 (EST)
> > > From: Pavel Roskin <[email protected]>
> > > cc: Jaroslav Kysela <[email protected]>, Pete Zaitcev <[email protected]>,
> > > <[email protected]>, <[email protected]>
> >
> > > The native YMF PCI driver from Linux-2.4.0-test12-pre5 works on my card:
> >
> > I did not have a chance to look at whatever is in 2.4, but from
> > reading Linus's e-mails I understand that Jaroslav made a new
> > port, which is probably unrelated to the stuff that I hastily
> > cooked up for 2.2 (I really wanted to play Doom on my new Sony).
>
> :-)))
I just found a message from Linus that says:
The other change is that I forward-ported the ymfpci driver from 2.2.18,
as it works better than the ALSA one on my now-to-be-main-laptop ;)
(in http://boudicca.tux.org/hypermail/linux-kernel/2000week50/0200.html)
Now I know why error messages looked so familiar. :)
In other words, Jaroslav was not involved.
I'll see what Linus did and send him updates, if any.
> But please note that opl3 is not enabled by the new driver, so people do
> lose some functionality they used to have.
I'll try to understand what this is all about. Honestly,
I do not know how OPL3 works and who uses it (it's a MIDI
thing, isn't it?)
--Pete
> The Linux-sound list appears to be dead (I don't see my message in
> http://www.kernelnotes.org/lnxlists/linux-sound/), so I'm sending to the
[email protected] is alive and well however.
> An additional problem is that opl3 cannot find the device unless I load
> and unload the old driver (ymf_sb). Probably the new driver should put the
> OPL3 interface to the legacy mode if it cannot handle it directly.
Probably
> Dec 5 18:08:16 fonzie kernel: ymfpci: ioctl cmd 0x5401
> Dec 5 18:08:50 fonzie last message repeated 9 times
Just debugging this is fine
> $ play spinout.wav
> sox: Unable to set audio speed to 5512 (set to 8000)
8Khz is the lower limit right now the way the board is driven.
Hello, Alan!
> > The Linux-sound list appears to be dead (I don't see my message in
> > http://www.kernelnotes.org/lnxlists/linux-sound/), so I'm sending to the
>
> [email protected] is alive and well however.
You cannot imagine how frustrating it was to search for the archive. I
couldn't find an up-to-date archive, and http://www.kernel.org keeps silence
about mailing lists. I cannot afford subscribing to every list just to
slightly polish support for my hardware.
> > Dec 5 18:08:16 fonzie kernel: ymfpci: ioctl cmd 0x5401
> > Dec 5 18:08:50 fonzie last message repeated 9 times
>
> Just debugging this is fine
Well, 0x5401 is TCGETS. Other sound drivers just ignore it. I believe the
drivers should only log the ioctls that are relevant to them (i.e.
sound-related ioctls for sound drivers) and are not implemented.
> > $ play spinout.wav
> > sox: Unable to set audio speed to 5512 (set to 8000)
>
> 8Khz is the lower limit right now the way the board is driven.
So, it's not just a matter of changing the constants under "case
SNDCTL_DSP_SPEED" in ymf_ioctl()? Actually, I hacked them to be
4000<rate<50000 and it worked fine, but I'll drop this part of my patch if
you believe it's unsafe.
Anyway, the problem with handing sox is solved by replacing all ENOTTY
with EINVAL in ymfpci.c. It has nothing to do with the lower frequency
limit. No other sound driver ever uses ENOTTY.
Regards,
Pavel Roskin
> So, it's not just a matter of changing the constants under "case
> SNDCTL_DSP_SPEED" in ymf_ioctl()? Actually, I hacked them to be
> 4000<rate<50000 and it worked fine, but I'll drop this part of my patch if
> you believe it's unsafe.
I'd keep it in the absence of other evidence. 8KHz is normally the low limit
for AC97 codec based systems, but if the rate adaption is done in front of
the codec then it may well be fine
[AC]
> > [email protected] is alive and well however.
[Pavel Roskin]
> You cannot imagine how frustrating it was to search for the archive.
> I couldn't find an up-to-date archive, and http://www.kernel.org keeps
> silence about mailing lists. I cannot afford subscribing to every
> list just to slightly polish support for my hardware.
Linus does take patches to the MAINTAINERS file from time to time. (:
In my opinion, the L: entries of MAINTAINERS ought to have URLs for
list archives, where available:
L: [email protected], <URL:http://www.xxxxxxx>
Perhaps archive URLs should be on W: lines but I think the L: lines are
appropriate -- keep related information together.
Peter