[alsa-devel] Backported sbxfi driver (UNTESTED!)
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi
On Thu, 09 Oct 2008 20:02:01 +0200 Takashi Iwai tiwai@suse.de wrote:
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi
Thank you, will test this later. As coincidental as it seems I pulled my X-Fi Prelude from my machine last night during cleaning, and never bothered reinstalling it as I had a bit of lost hope. This is definitely a huge start.
All of us pushing Creative to release some specs without a ridiculous NDA would be a big next step.
Cheers,
Bren
I'm using fedora 9 with 2.6.26.5.
Should I just be able to download
ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.bz2
configure and make install it and that should be it? I mean, do I need to do anything with my modprobe.conf?
This is what I had when I had an emu10k1 card, is this driver called emu20k1?
# ALSA portion # alias char-major-116 snd # alias snd-card-0 snd-emu10k1 #alias midi snd-synth-emu10k1 #install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && /usr/sbin/alsactl restore >/dev/null 2>&1 || : #options snd-emu10k1 index=0 #remove snd-emu10k1 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove # OSS/Free portion # alias char-major-14 soundcore # alias sound-slot-0 snd-card-0 # card #1 #alias sound-service-0-0 snd-mixer-oss #alias sound-service-0-1 snd-seq-oss #alias sound-service-0-3 snd-pcm-oss #alias sound-service-0-8 snd-seq-oss #alias sound-service-0-12 snd-pcm-oss #options snd-hda-intel index=0 #remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-hda-intel #install snd-usb-audio /sbin/modprobe --ignore-install snd-usb-audio && /usr/sbin/alsactl restore >/dev/null 2>&1 || : #remove snd-usb-audio { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-usb-audio #options snd-usb-audio index=2 #options cdc-acmsu vendor=0x22b8 product=0x2a64 #alias snd-card-0 snd-hda-intel #options snd-card-0 index=0
On Thu, 2008-10-09 at 20:02 +0200, Takashi Iwai wrote:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hello Takashi,
I will have plenty of patches for this fairly soon. Stay tuned.
William
On Thu, 2008-10-09 at 20:02 +0200, Takashi Iwai wrote:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hmm,
I have a fedora 9 machine and I installed your alsa-driver snapshot, which does have snd-sbxfi.
However, I am getting tons of errors
modprobe snd-pcm FATAL: Error inserting snd_pcm (/lib/modules/2.6.26.5-45.fc9.i686/kernel/sound/acore/snd-pcm.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error running install command for snd_pcm snd_pcm: Unknown symbol snd_info_register snd_pcm: Unknown symbol snd_info_create_module_entry snd_pcm: Unknown symbol snd_timer_notify snd_pcm: Unknown symbol snd_timer_interrupt snd_pcm: Unknown symbol snd_info_free_entry snd_pcm: Unknown symbol snd_add_device_sysfs_file snd_pcm: Unknown symbol snd_info_get_str snd_pcm: Unknown symbol snd_verbose_printk snd_pcm: Unknown symbol snd_ctl_register_ioctl snd_pcm: Unknown symbol snd_card_file_add snd_pcm: Unknown symbol snd_iprintf snd_pcm: Unknown symbol snd_major snd_pcm: Unknown symbol snd_unregister_device snd_pcm: Unknown symbol snd_timer_new snd_pcm: Unknown symbol snd_device_new snd_pcm: Unknown symbol snd_ctl_unregister_ioctl snd_pcm: Unknown symbol snd_lookup_minor_data snd_pcm: Unknown symbol snd_info_create_card_entry snd_pcm: Unknown symbol snd_power_wait snd_pcm: Unknown symbol snd_device_free snd_pcm: Unknown symbol snd_card_file_remove snd_pcm: Unknown symbol snd_register_device_for_dev snd_pcm: Unknown symbol snd_device_register snd_pcm: Unknown symbol snd_info_get_line snd: Unknown symbol unregister_sound_special snd: Unknown symbol register_sound_special_device snd: Unknown symbol sound_class snd_timer: Unknown symbol snd_info_register snd_timer: Unknown symbol snd_info_create_module_entry snd_timer: Unknown symbol snd_info_free_entry snd_timer: Unknown symbol snd_verbose_printk snd_timer: Unknown symbol snd_iprintf snd_timer: Unknown symbol snd_ecards_limit snd_timer: Unknown symbol snd_oss_info_register snd_timer: Unknown symbol snd_unregister_device snd_timer: Unknown symbol snd_device_new snd_timer: Unknown symbol snd_register_device_for_dev snd: Unknown symbol unregister_sound_special snd: Unknown symbol register_sound_special_device snd: Unknown symbol sound_class snd_timer: Unknown symbol snd_info_register snd_timer: Unknown symbol snd_info_create_module_entry snd_timer: Unknown symbol snd_info_free_entry snd_timer: Unknown symbol snd_verbose_printk snd_timer: Unknown symbol snd_iprintf snd_timer: Unknown symbol snd_ecards_limit snd_timer: Unknown symbol snd_oss_info_register snd_timer: Unknown symbol snd_unregister_device snd_timer: Unknown symbol snd_device_new snd_timer: Unknown symbol snd_register_device_for_dev snd_pcm: Unknown symbol snd_info_register snd_pcm: Unknown symbol snd_info_create_module_entry snd_pcm: Unknown symbol snd_timer_notify snd_pcm: Unknown symbol snd_timer_interrupt snd_pcm: Unknown symbol snd_info_free_entry snd_pcm: Unknown symbol snd_add_device_sysfs_file snd_pcm: Unknown symbol snd_info_get_str snd_pcm: Unknown symbol snd_verbose_printk snd_pcm: Unknown symbol snd_ctl_register_ioctl snd_pcm: Unknown symbol snd_card_file_add snd_pcm: Unknown symbol snd_iprintf snd_pcm: Unknown symbol snd_major snd_pcm: Unknown symbol snd_unregister_device snd_pcm: Unknown symbol snd_timer_new snd_pcm: Unknown symbol snd_device_new snd_pcm: Unknown symbol snd_ctl_unregister_ioctl snd_pcm: Unknown symbol snd_lookup_minor_data snd_pcm: Unknown symbol snd_info_create_card_entry snd_pcm: Unknown symbol snd_power_wait snd_pcm: Unknown symbol snd_device_free snd_pcm: Unknown symbol snd_card_file_remove snd_pcm: Unknown symbol snd_register_device_for_dev snd_pcm: Unknown symbol snd_device_register snd_pcm: Unknown symbol snd_info_get_line
what do i do? On Thu, 2008-10-09 at 20:02 +0200, Takashi Iwai wrote:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Takashi Iwai wrote:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
http://james.dutton.googlepages.com/home
There might be some extra info in the emu20k1.h file there. I do not have much time, but I will update the emu20k1.h file with any register info people need.
Kind Regards
James
Nevermind,
I got it to compile/install on my fedora machine, and the modules load. However, when I run "alsamixer" or click on gnome's mixer applet, it locks my entire system. I used your tarball from your site... sbxfi is loaded, etc.
Linux home 2.6.26.5-45.fc9.i686 #1 SMP Sat Sep 20 03:45:00 EDT 2008 i686 i686 i386 GNU/Linux rpmq alsa alsa-oss-devel-1.0.15-0.1.fc9.i386 alsa-lib-1.0.17-2.fc9.i386 alsa-oss-1.0.15-0.1.fc9.i386 alsa-utils-1.0.17-2.fc9.i386 alsa-plugins-pulseaudio-1.0.16-4.fc9.i386 alsa-plugins-oss-1.0.16-4.fc9.i386 alsa-oss-libs-1.0.15-0.1.fc9.i386 alsa-lib-devel-1.0.17-2.fc9.i386 alsa-tools-1.0.16-4.fc9.i386 bluez-utils-alsa-3.35-5.fc9.i386
cat /etc/modprobe.conf alias eth0 e100 alias scsi_hostadapter ata_piix
# ivtv (PVR-150MCE) alias char-major-81 ivtv options ivtv enc_mpg_buffers=16 ivtv_first_minor=1 alias gspca /dev/video1 #pre-install gspca /sbin/modprobe ivtv # ALSA portion alias char-major-116 snd alias snd-card-0 snd-sbxfi alias midi snd-synth-sbxfi install snd-sbxfi /sbin/modprobe --ignore-install snd-sbxfi && /usr/sbin/alsactl restore >/dev/null 2>&1 || : options snd-sbxfi index=0 remove snd-sbxfi { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove # OSS/Free portion alias char-major-14 soundcore alias sound-slot-0 snd-card-0 # card #1 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss options snd-hda-intel index=0 remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-hda-intel install snd-usb-audio /sbin/modprobe --ignore-install snd-usb-audio && /usr/sbin/alsactl restore >/dev/null 2>&1 || : remove snd-usb-audio { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-usb-audio options snd-usb-audio index=2 options cdc-acmsu vendor=0x22b8 product=0x2a64 alias snd-card-0 snd-hda-intel options snd-card-0 index=0
On Thu, 2008-10-09 at 20:02 +0200, Takashi Iwai wrote:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Sorry for the multiple posts, but once I rmmod snd-sbxfi, running mixer does fine. It seems if I have snd-sbxfi loaded and I run alsamixer, it locks the entire system.
On Thu, 2008-10-09 at 20:02 +0200, Takashi Iwai wrote:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Thu, 09 Oct 2008 15:17:58 -0500, Ted T. Logian wrote:
Sorry for the multiple posts, but once I rmmod snd-sbxfi, running mixer does fine. It seems if I have snd-sbxfi loaded and I run alsamixer, it locks the entire system.
So, do you mean loading the driver itself doesn't lock up? If so, it's better than I expected.
Did you run ever PCM playback/capture before that? This is more dangerous :)
Also, please give your hardware details, as there are different models for X-Fi, and some are handled pretty differently.
[BTW, please stop top-posting, and avoid HTML mails for ML. It's easy to switch to normal (plain) mail mode on Gmail, just a click.]
thanks,
Takashi
At Thu, 09 Oct 2008 20:50:52 +0100, James Courtier-Dutton wrote:
Takashi Iwai wrote:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
http://james.dutton.googlepages.com/home
There might be some extra info in the emu20k1.h file there. I do not have much time, but I will update the emu20k1.h file with any register info people need.
Great, I'll have a look later.
thanks,
Takashi
On Fri, 2008-10-10 at 08:01 +0200, Takashi Iwai wrote:
At Thu, 09 Oct 2008 15:17:58 -0500, Ted T. Logian wrote:
Sorry for the multiple posts, but once I rmmod snd-sbxfi, running mixer does fine. It seems if I have snd-sbxfi loaded and I run alsamixer, it locks the entire system.
So, do you mean loading the driver itself doesn't lock up? If so, it's better than I expected.
Did you run ever PCM playback/capture before that? This is more dangerous :)
Also, please give your hardware details, as there are different models for X-Fi, and some are handled pretty differently.
[BTW, please stop top-posting, and avoid HTML mails for ML. It's easy to switch to normal (plain) mail mode on Gmail, just a click.]
thanks,
Takashi
I think perhaps from uninstalling pulseaudio I got further. I can use mixer now, and it even has a "Master" device, but nothing else...
however, I do get a lock up later.
I get this from running aplay, too, if this helps...
aplay BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: [<c04fe489>] __list_add+0x6/0x4a *pde = 7c8a4067 Oops: 0000 [#1] SMP Modules linked in: bridge bnep rfcomm l2cap autofs4 sunrpc ipv6 nf_conntrack_ftp nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables fuse dm_mirror dm_log dm_mod snd_hda_intel snd_usb_audio snd_sbxfi pl2303 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq hci_usb bluetooth tuner_simple tuner_types snd_pcm_oss tda9887 snd_mixer_oss tda8290 snd_pcm snd_usb_lib snd_rawmidi snd_seq_device wm8775 gspca snd_timer cx25840 tuner nvidia(P) snd_page_alloc snd_hwdep sr_mod e100 usbserial cdrom snd soundcore i2c_i801 ivtv compat_ioctl32 i2c_algo_bit cx2341x v4l2_common tveeprom videodev pcspkr joydev iTCO_wdt iTCO_vendor_support i2c_core dcdbas v4l1_compat serio_raw mii sg ata_piix ata_generic pata_acpi libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]
Pid: 3031, comm: aplay Tainted: P (2.6.26.5-45.fc9.i686 #1) EIP: 0060:[<c04fe489>] EFLAGS: 00010046 CPU: 0 EIP is at __list_add+0x6/0x4a EAX: f7b9f1f8 EBX: f7b9f1f8 ECX: 00000000 EDX: f3de5138 ESI: f3de5100 EDI: f7b9f100 EBP: f7322de4 ESP: f7322de0 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process aplay (pid: 3031, ti=f7322000 task=f28abe80 task.ti=f7322000) Stack: f7b9f124 f7322dec c04fe4d7 f7322e00 f9cc32ee f28a1800 f7322e54 f709a910 f7322e14 f9cc338a 00000000 f7322e54 f709a910 f7322e28 f9baedc2 f70f9100 fffffff2 f709a800 f7322e64 f9baee9c f7322e54 00000000 f2847200 f709a920 Call Trace: [<c04fe4d7>] ? list_add+0xa/0xf [<f9cc32ee>] ? sbxfi_port_alloc+0x80/0x95 [snd_sbxfi] [<f9cc338a>] ? sbxfi_playback_open+0x13/0x82 [snd_sbxfi] [<f9baedc2>] ? snd_pcm_open_substream+0x3a/0x72 [snd_pcm] [<f9baee9c>] ? snd_pcm_open+0xa2/0x179 [snd_pcm] [<c0420db2>] ? default_wake_function+0x0/0xd [<f935a1b3>] ? snd_lookup_minor_data+0x3d/0x44 [snd] [<f9baefbf>] ? snd_pcm_playback_open+0x23/0x26 [snd_pcm] [<f935a4e3>] ? snd_open+0xc1/0x11e [snd] [<c0487c12>] ? chrdev_open+0x116/0x132 [<c0484178>] ? __dentry_open+0x10e/0x1fc [<c04842ed>] ? nameidata_to_filp+0x1f/0x33 [<c0487afc>] ? chrdev_open+0x0/0x132 [<c048f1ec>] ? do_filp_open+0x33e/0x6b0 [<f935a7fe>] ? snd_card_file_remove+0xce/0xd8 [snd] [<c0483ee8>] ? get_unused_fd_flags+0x64/0xc5 [<c0483f89>] ? do_sys_open+0x40/0xb6 [<c0484041>] ? sys_open+0x1e/0x26 [<c0404c32>] ? syscall_call+0x7/0xb [<c0630000>] ? down_read+0x27/0x29 ======================= Code: 6e c0 e8 cb 08 13 00 0f 0b 83 c4 0c eb fe 89 58 04 89 03 c7 42 04 00 02 20 00 c7 02 00 01 10 00 8b 5d fc c9 c3 55 89 e5 53 89 c3 <8b> 41 04 39 d0 74 14 51 50 52 68 f7 5a 6e c0 e8 93 08 13 00 0f EIP: [<c04fe489>] __list_add+0x6/0x4a SS:ESP 0068:f7322de0 ---[ end trace 0611fd70d756e2b7 ]--- Segmentation fault
At Fri, 10 Oct 2008 01:26:15 -0500, Ted T. Logian wrote:
On Fri, 2008-10-10 at 08:01 +0200, Takashi Iwai wrote:
At Thu, 09 Oct 2008 15:17:58 -0500, Ted T. Logian wrote:
Sorry for the multiple posts, but once I rmmod snd-sbxfi, running mixer does fine. It seems if I have snd-sbxfi loaded and I run alsamixer, it locks the entire system.
So, do you mean loading the driver itself doesn't lock up? If so, it's better than I expected.
Did you run ever PCM playback/capture before that? This is more dangerous :)
Also, please give your hardware details, as there are different models for X-Fi, and some are handled pretty differently.
[BTW, please stop top-posting, and avoid HTML mails for ML. It's easy to switch to normal (plain) mail mode on Gmail, just a click.]
thanks,
Takashi
I think perhaps from uninstalling pulseaudio I got further. I can use mixer now, and it even has a "Master" device, but nothing else...
however, I do get a lock up later.
I get this from running aplay, too, if this helps...
Thanks! That's rather a stupid bug. The patch is below.
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 8066bf4..8a0eea0 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -831,7 +831,7 @@ static struct sbxfi_port *sbxfi_port_alloc(struct sbxfi *chip, port->src[0] = src; port->src[1] = src + 1; spin_lock_irq(&chip->port_lock); - list_add(&chip->port_list, &port->list); + list_add(&port->list, &chip->port_list); spin_unlock_irq(&chip->port_lock); return port; }
With this patch, the driver does output audio, but the DAC dies and we only get noise. Going to try to whack at this with a larger hammer, it's a fairly obvious bug, it just needs some debugging. The noise sounds like the write pointer is off-by-one; it sort of resembles the source audio.
Some patches for mixer stuff are coming soon (next few hours probably)... as well as chip revision detection and some other niceities.
William
On Fri, 2008-10-10 at 08:46 +0200, Takashi Iwai wrote:
At Fri, 10 Oct 2008 01:26:15 -0500, Ted T. Logian wrote:
On Fri, 2008-10-10 at 08:01 +0200, Takashi Iwai wrote:
At Thu, 09 Oct 2008 15:17:58 -0500, Ted T. Logian wrote:
Sorry for the multiple posts, but once I rmmod snd-sbxfi, running mixer does fine. It seems if I have snd-sbxfi loaded and I run alsamixer, it locks the entire system.
So, do you mean loading the driver itself doesn't lock up? If so, it's better than I expected.
Did you run ever PCM playback/capture before that? This is more dangerous :)
Also, please give your hardware details, as there are different models for X-Fi, and some are handled pretty differently.
[BTW, please stop top-posting, and avoid HTML mails for ML. It's easy to switch to normal (plain) mail mode on Gmail, just a click.]
thanks,
Takashi
I think perhaps from uninstalling pulseaudio I got further. I can use mixer now, and it even has a "Master" device, but nothing else...
however, I do get a lock up later.
I get this from running aplay, too, if this helps...
Thanks! That's rather a stupid bug. The patch is below.
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 8066bf4..8a0eea0 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -831,7 +831,7 @@ static struct sbxfi_port *sbxfi_port_alloc(struct sbxfi *chip, port->src[0] = src; port->src[1] = src + 1; spin_lock_irq(&chip->port_lock);
- list_add(&chip->port_list, &port->list);
- list_add(&port->list, &chip->port_list); spin_unlock_irq(&chip->port_lock); return port;
} _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Fri, 10 Oct 2008 13:17:32 -0500, William Pitcock wrote:
With this patch, the driver does output audio, but the DAC dies and we only get noise. Going to try to whack at this with a larger hammer, it's a fairly obvious bug, it just needs some debugging. The noise sounds like the write pointer is off-by-one; it sort of resembles the source audio.
OK, good to hear that it's not always locking up.
Some patches for mixer stuff are coming soon (next few hours probably)... as well as chip revision detection and some other niceities.
Great. I'm looking forward to your patches.
Meanwhile, the patch below might improve something. Basically test sets the DMA mask, and use the continuous pages instead of SG buffers (in case it's the error cause). Give it a try. (And I'll update the git tree, too).
Also, try different XXX_* flags in sbxfi.c. The default setting isn't completely identical with OSS v4 driver.
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 8a0eea0..86dd025 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -66,6 +66,9 @@ enum { #define SBXFI_MAX_BUFFER (SBXFI_TLB_PAGES * SBXFI_PAGE_SIZE) #define SBXFI_MAX_SRCS 128 /* 256 / 2 */ #define SBXFI_TIMER_FREQ 96000 +/* FIXME: which mask? */ +/* #define SBXFI_DMA_MASK DMA_32BIT_MASK */ +#define SBXFI_DMA_MASK DMA_28BIT_MASK
#define MAX_CHANNELS 2
@@ -154,6 +157,9 @@ struct sbxfi { /* constant ticks */ /* #define XXX_CONST_TICKS (96000 * 5 / 1000) */
+/* SG or continuous buffer */ +#undef XXX_USE_SG + #ifdef XXX_48K_ONLY #define BASE_RATE 48000 #else @@ -796,8 +802,13 @@ static int sbxfi_setup_tlb(struct sbxfi *chip, struct sbxfi_port *port,
pgtbl = (u32*)chip->tlb.area; pgtbl += port->tlb_index; +#ifdef XXX_USE_SG for (p = 0; p < pages; p++, pgtbl++) *pgtbl = snd_pcm_sgbuf_get_addr(substream, p * SBXFI_PAGE_SIZE); +#else + for (p = 0; p < pages; p++, pgtbl++) + *pgtbl = substream->runtime->dma_addr + p * SBXFI_PAGE_SIZE; +#endif
return 0; } @@ -1319,7 +1330,9 @@ static struct snd_pcm_ops sbxfi_playback_ops = { .prepare = sbxfi_playback_prepare, .trigger = sbxfi_playback_trigger, .pointer = sbxfi_pcm_pointer, +#ifdef XXX_USE_SG .page = snd_pcm_sgbuf_ops_page, +#endif };
static struct snd_pcm_ops sbxfi_capture_ops = { @@ -1331,7 +1344,9 @@ static struct snd_pcm_ops sbxfi_capture_ops = { .prepare = sbxfi_capture_prepare, .trigger = sbxfi_capture_trigger, .pointer = sbxfi_pcm_pointer, +#ifdef XXX_USE_SG .page = snd_pcm_sgbuf_ops_page, +#endif };
static int __devinit sbxfi_create_pcm(struct sbxfi *chip) @@ -1351,9 +1366,15 @@ static int __devinit sbxfi_create_pcm(struct sbxfi *chip) pcm->info_flags = SNDRV_PCM_INFO_HALF_DUPLEX; #endif strcpy(pcm->name, "SB-XFi"); +#ifdef XXX_USE_SG snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024); +#else + snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, + snd_dma_pci_data(chip->pci), + 1024 * 64, 32 * 1024 * 1024); +#endif chip->pcm = pcm; return 0; } @@ -1781,6 +1802,13 @@ static int __devinit sbxfi_create(struct snd_card *card, struct pci_dev *pci, if (err < 0) goto error;
+ if (pci_set_dma_mask(pci, SBXFI_DMA_MASK) < 0 || + pci_set_consistent_dma_mask(pci, SBXFI_DMA_MASK) < 0) { + printk(KERN_ERR PFX "Unable to set DMA mask\n"); + err = -EINVAL; + goto error; + } + err = sbxfi_alloc_buffer(chip); if (err < 0) goto error;
Hello,
Serial console output from my try with this driver in various modes:
nenolod@petrie:~$ aplay -D hw:2,0 ~/13\ -\ Emerge\ (Junkie\ XL\ Remix )\ [Explicit].wav Playing WAVE '/home/nenolod/13 - Emerge (Junkie XL Remix) [Explicit].wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout ^C <system hardlocks on interrupt>
Noise is now on the right channel only.
It might make more sense to poll for the DAC reset in the interrupt handler. I have noticed that the card generates an interrupt request in Windows once the DAC is online.
Something leads me to believe that the DMA mask is 32 bits, but given that the behaviour is similar in both instances, I am unsure.
William
On Sat, 2008-10-11 at 18:01 +0200, Takashi Iwai wrote:
At Fri, 10 Oct 2008 13:17:32 -0500, William Pitcock wrote:
With this patch, the driver does output audio, but the DAC dies and we only get noise. Going to try to whack at this with a larger hammer, it's a fairly obvious bug, it just needs some debugging. The noise sounds like the write pointer is off-by-one; it sort of resembles the source audio.
OK, good to hear that it's not always locking up.
Some patches for mixer stuff are coming soon (next few hours probably)... as well as chip revision detection and some other niceities.
Great. I'm looking forward to your patches.
Meanwhile, the patch below might improve something. Basically test sets the DMA mask, and use the continuous pages instead of SG buffers (in case it's the error cause). Give it a try. (And I'll update the git tree, too).
Also, try different XXX_* flags in sbxfi.c. The default setting isn't completely identical with OSS v4 driver.
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 8a0eea0..86dd025 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -66,6 +66,9 @@ enum { #define SBXFI_MAX_BUFFER (SBXFI_TLB_PAGES * SBXFI_PAGE_SIZE) #define SBXFI_MAX_SRCS 128 /* 256 / 2 */ #define SBXFI_TIMER_FREQ 96000 +/* FIXME: which mask? */ +/* #define SBXFI_DMA_MASK DMA_32BIT_MASK */ +#define SBXFI_DMA_MASK DMA_28BIT_MASK
#define MAX_CHANNELS 2
@@ -154,6 +157,9 @@ struct sbxfi { /* constant ticks */ /* #define XXX_CONST_TICKS (96000 * 5 / 1000) */
+/* SG or continuous buffer */ +#undef XXX_USE_SG
#ifdef XXX_48K_ONLY #define BASE_RATE 48000 #else @@ -796,8 +802,13 @@ static int sbxfi_setup_tlb(struct sbxfi *chip, struct sbxfi_port *port,
pgtbl = (u32*)chip->tlb.area; pgtbl += port->tlb_index; +#ifdef XXX_USE_SG for (p = 0; p < pages; p++, pgtbl++) *pgtbl = snd_pcm_sgbuf_get_addr(substream, p * SBXFI_PAGE_SIZE); +#else
- for (p = 0; p < pages; p++, pgtbl++)
*pgtbl = substream->runtime->dma_addr + p * SBXFI_PAGE_SIZE;+#endif
return 0; } @@ -1319,7 +1330,9 @@ static struct snd_pcm_ops sbxfi_playback_ops = { .prepare = sbxfi_playback_prepare, .trigger = sbxfi_playback_trigger, .pointer = sbxfi_pcm_pointer, +#ifdef XXX_USE_SG .page = snd_pcm_sgbuf_ops_page, +#endif };
static struct snd_pcm_ops sbxfi_capture_ops = { @@ -1331,7 +1344,9 @@ static struct snd_pcm_ops sbxfi_capture_ops = { .prepare = sbxfi_capture_prepare, .trigger = sbxfi_capture_trigger, .pointer = sbxfi_pcm_pointer, +#ifdef XXX_USE_SG .page = snd_pcm_sgbuf_ops_page, +#endif };
static int __devinit sbxfi_create_pcm(struct sbxfi *chip) @@ -1351,9 +1366,15 @@ static int __devinit sbxfi_create_pcm(struct sbxfi *chip) pcm->info_flags = SNDRV_PCM_INFO_HALF_DUPLEX; #endif strcpy(pcm->name, "SB-XFi"); +#ifdef XXX_USE_SG snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024); +#else
- snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
snd_dma_pci_data(chip->pci),1024 * 64, 32 * 1024 * 1024);+#endif chip->pcm = pcm; return 0; } @@ -1781,6 +1802,13 @@ static int __devinit sbxfi_create(struct snd_card *card, struct pci_dev *pci, if (err < 0) goto error;
- if (pci_set_dma_mask(pci, SBXFI_DMA_MASK) < 0 ||
pci_set_consistent_dma_mask(pci, SBXFI_DMA_MASK) < 0) {printk(KERN_ERR PFX "Unable to set DMA mask\n");err = -EINVAL;goto error;- }
- err = sbxfi_alloc_buffer(chip); if (err < 0) goto error;
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hello,
Actually, I am certain that the DMA mask is 32 bits.
William
On Sat, 2008-10-11 at 12:36 -0500, William Pitcock wrote:
Hello,
Serial console output from my try with this driver in various modes:
nenolod@petrie:~$ aplay -D hw:2,0 ~/13\ -\ Emerge\ (Junkie\ XL\ Remix )\ [Explicit].wav Playing WAVE '/home/nenolod/13 - Emerge (Junkie XL Remix) [Explicit].wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout ^C
<system hardlocks on interrupt>
Noise is now on the right channel only.
It might make more sense to poll for the DAC reset in the interrupt handler. I have noticed that the card generates an interrupt request in Windows once the DAC is online.
Something leads me to believe that the DMA mask is 32 bits, but given that the behaviour is similar in both instances, I am unsure.
William
On Sat, 2008-10-11 at 18:01 +0200, Takashi Iwai wrote:
At Fri, 10 Oct 2008 13:17:32 -0500, William Pitcock wrote:
With this patch, the driver does output audio, but the DAC dies and we only get noise. Going to try to whack at this with a larger hammer, it's a fairly obvious bug, it just needs some debugging. The noise sounds like the write pointer is off-by-one; it sort of resembles the source audio.
OK, good to hear that it's not always locking up.
Some patches for mixer stuff are coming soon (next few hours probably)... as well as chip revision detection and some other niceities.
Great. I'm looking forward to your patches.
Meanwhile, the patch below might improve something. Basically test sets the DMA mask, and use the continuous pages instead of SG buffers (in case it's the error cause). Give it a try. (And I'll update the git tree, too).
Also, try different XXX_* flags in sbxfi.c. The default setting isn't completely identical with OSS v4 driver.
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 8a0eea0..86dd025 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -66,6 +66,9 @@ enum { #define SBXFI_MAX_BUFFER (SBXFI_TLB_PAGES * SBXFI_PAGE_SIZE) #define SBXFI_MAX_SRCS 128 /* 256 / 2 */ #define SBXFI_TIMER_FREQ 96000 +/* FIXME: which mask? */ +/* #define SBXFI_DMA_MASK DMA_32BIT_MASK */ +#define SBXFI_DMA_MASK DMA_28BIT_MASK
#define MAX_CHANNELS 2
@@ -154,6 +157,9 @@ struct sbxfi { /* constant ticks */ /* #define XXX_CONST_TICKS (96000 * 5 / 1000) */
+/* SG or continuous buffer */ +#undef XXX_USE_SG
#ifdef XXX_48K_ONLY #define BASE_RATE 48000 #else @@ -796,8 +802,13 @@ static int sbxfi_setup_tlb(struct sbxfi *chip, struct sbxfi_port *port,
pgtbl = (u32*)chip->tlb.area; pgtbl += port->tlb_index; +#ifdef XXX_USE_SG for (p = 0; p < pages; p++, pgtbl++) *pgtbl = snd_pcm_sgbuf_get_addr(substream, p * SBXFI_PAGE_SIZE); +#else
- for (p = 0; p < pages; p++, pgtbl++)
*pgtbl = substream->runtime->dma_addr + p * SBXFI_PAGE_SIZE;+#endif
return 0; } @@ -1319,7 +1330,9 @@ static struct snd_pcm_ops sbxfi_playback_ops = { .prepare = sbxfi_playback_prepare, .trigger = sbxfi_playback_trigger, .pointer = sbxfi_pcm_pointer, +#ifdef XXX_USE_SG .page = snd_pcm_sgbuf_ops_page, +#endif };
static struct snd_pcm_ops sbxfi_capture_ops = { @@ -1331,7 +1344,9 @@ static struct snd_pcm_ops sbxfi_capture_ops = { .prepare = sbxfi_capture_prepare, .trigger = sbxfi_capture_trigger, .pointer = sbxfi_pcm_pointer, +#ifdef XXX_USE_SG .page = snd_pcm_sgbuf_ops_page, +#endif };
static int __devinit sbxfi_create_pcm(struct sbxfi *chip) @@ -1351,9 +1366,15 @@ static int __devinit sbxfi_create_pcm(struct sbxfi *chip) pcm->info_flags = SNDRV_PCM_INFO_HALF_DUPLEX; #endif strcpy(pcm->name, "SB-XFi"); +#ifdef XXX_USE_SG snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024); +#else
- snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
snd_dma_pci_data(chip->pci),1024 * 64, 32 * 1024 * 1024);+#endif chip->pcm = pcm; return 0; } @@ -1781,6 +1802,13 @@ static int __devinit sbxfi_create(struct snd_card *card, struct pci_dev *pci, if (err < 0) goto error;
- if (pci_set_dma_mask(pci, SBXFI_DMA_MASK) < 0 ||
pci_set_consistent_dma_mask(pci, SBXFI_DMA_MASK) < 0) {printk(KERN_ERR PFX "Unable to set DMA mask\n");err = -EINVAL;goto error;- }
- err = sbxfi_alloc_buffer(chip); if (err < 0) goto error;
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Sat, 11 Oct 2008 12:36:09 -0500, William Pitcock wrote:
Hello,
Serial console output from my try with this driver in various modes:
nenolod@petrie:~$ aplay -D hw:2,0 ~/13\ -\ Emerge\ (Junkie\ XL\ Remix )\ [Explicit].wav Playing WAVE '/home/nenolod/13 - Emerge (Junkie XL Remix) [Explicit].wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout ^C
<system hardlocks on interrupt>
Could you build with XXX_CONST_TIMER defined? This will disable the adaptive timer-resolution handling I added to the driver, which doesn't exist in OSS sbxfi code at all.
Noise is now on the right channel only.
Does it mean that the left channel plays normally as expected? Also, which sample rate are you using? I'm curious whether the sample rate tracking is correct...
It might make more sense to poll for the DAC reset in the interrupt handler. I have noticed that the card generates an interrupt request in Windows once the DAC is online.
Interesting... Maybe putting some debug prints in interrupt handler and else would help a bit for more understanding.
Something leads me to believe that the DMA mask is 32 bits, but given that the behaviour is similar in both instances, I am unsure.
This isn't a critical issue right now. It can be figured out safely later.
Also, could you show the hardware information I asked in other posts? There are certainly cases that the driver works and hangs. The difference likely comes from the board type, I guess.
thanks,
Takashi
William
On Sat, 2008-10-11 at 18:01 +0200, Takashi Iwai wrote:
At Fri, 10 Oct 2008 13:17:32 -0500, William Pitcock wrote:
With this patch, the driver does output audio, but the DAC dies and we only get noise. Going to try to whack at this with a larger hammer, it's a fairly obvious bug, it just needs some debugging. The noise sounds like the write pointer is off-by-one; it sort of resembles the source audio.
OK, good to hear that it's not always locking up.
Some patches for mixer stuff are coming soon (next few hours probably)... as well as chip revision detection and some other niceities.
Great. I'm looking forward to your patches.
Meanwhile, the patch below might improve something. Basically test sets the DMA mask, and use the continuous pages instead of SG buffers (in case it's the error cause). Give it a try. (And I'll update the git tree, too).
Also, try different XXX_* flags in sbxfi.c. The default setting isn't completely identical with OSS v4 driver.
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 8a0eea0..86dd025 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -66,6 +66,9 @@ enum { #define SBXFI_MAX_BUFFER (SBXFI_TLB_PAGES * SBXFI_PAGE_SIZE) #define SBXFI_MAX_SRCS 128 /* 256 / 2 */ #define SBXFI_TIMER_FREQ 96000 +/* FIXME: which mask? */ +/* #define SBXFI_DMA_MASK DMA_32BIT_MASK */ +#define SBXFI_DMA_MASK DMA_28BIT_MASK
#define MAX_CHANNELS 2
@@ -154,6 +157,9 @@ struct sbxfi { /* constant ticks */ /* #define XXX_CONST_TICKS (96000 * 5 / 1000) */
+/* SG or continuous buffer */ +#undef XXX_USE_SG
#ifdef XXX_48K_ONLY #define BASE_RATE 48000 #else @@ -796,8 +802,13 @@ static int sbxfi_setup_tlb(struct sbxfi *chip, struct sbxfi_port *port,
pgtbl = (u32*)chip->tlb.area; pgtbl += port->tlb_index; +#ifdef XXX_USE_SG for (p = 0; p < pages; p++, pgtbl++) *pgtbl = snd_pcm_sgbuf_get_addr(substream, p * SBXFI_PAGE_SIZE); +#else
- for (p = 0; p < pages; p++, pgtbl++)
*pgtbl = substream->runtime->dma_addr + p * SBXFI_PAGE_SIZE;+#endif
return 0; } @@ -1319,7 +1330,9 @@ static struct snd_pcm_ops sbxfi_playback_ops = { .prepare = sbxfi_playback_prepare, .trigger = sbxfi_playback_trigger, .pointer = sbxfi_pcm_pointer, +#ifdef XXX_USE_SG .page = snd_pcm_sgbuf_ops_page, +#endif };
static struct snd_pcm_ops sbxfi_capture_ops = { @@ -1331,7 +1344,9 @@ static struct snd_pcm_ops sbxfi_capture_ops = { .prepare = sbxfi_capture_prepare, .trigger = sbxfi_capture_trigger, .pointer = sbxfi_pcm_pointer, +#ifdef XXX_USE_SG .page = snd_pcm_sgbuf_ops_page, +#endif };
static int __devinit sbxfi_create_pcm(struct sbxfi *chip) @@ -1351,9 +1366,15 @@ static int __devinit sbxfi_create_pcm(struct sbxfi *chip) pcm->info_flags = SNDRV_PCM_INFO_HALF_DUPLEX; #endif strcpy(pcm->name, "SB-XFi"); +#ifdef XXX_USE_SG snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci), 1024 * 64, 32 * 1024 * 1024); +#else
- snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
snd_dma_pci_data(chip->pci),1024 * 64, 32 * 1024 * 1024);+#endif chip->pcm = pcm; return 0; } @@ -1781,6 +1802,13 @@ static int __devinit sbxfi_create(struct snd_card *card, struct pci_dev *pci, if (err < 0) goto error;
- if (pci_set_dma_mask(pci, SBXFI_DMA_MASK) < 0 ||
pci_set_consistent_dma_mask(pci, SBXFI_DMA_MASK) < 0) {printk(KERN_ERR PFX "Unable to set DMA mask\n");err = -EINVAL;goto error;- }
- err = sbxfi_alloc_buffer(chip); if (err < 0) goto error;
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Sat, 11 Oct 2008 19:41:59 +0200, I wrote:
At Sat, 11 Oct 2008 12:36:09 -0500, William Pitcock wrote:
Hello,
Serial console output from my try with this driver in various modes:
nenolod@petrie:~$ aplay -D hw:2,0 ~/13\ -\ Emerge\ (Junkie\ XL\ Remix )\ [Explicit].wav Playing WAVE '/home/nenolod/13 - Emerge (Junkie XL Remix) [Explicit].wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout XFi DAC reset timeout ^C
<system hardlocks on interrupt>
Could you build with XXX_CONST_TIMER defined?
Typo: it reads XXX_CONST_TICKS.
Takashi
Hi,
On Sat, 2008-10-11 at 19:41 +0200, Takashi Iwai wrote:
Could you build with XXX_CONST_TIMER defined? This will disable the adaptive timer-resolution handling I added to the driver, which doesn't exist in OSS sbxfi code at all.
No change in behaviour. It survives a little longer, but then the system hardlocks... without me even touching the keyboard even.
Noise is now on the right channel only.
Does it mean that the left channel plays normally as expected? Also, which sample rate are you using? I'm curious whether the sample rate tracking is correct...
No. The left channel is silent.
It might make more sense to poll for the DAC reset in the interrupt handler. I have noticed that the card generates an interrupt request
in
Windows once the DAC is online.
Interesting... Maybe putting some debug prints in interrupt handler and else would help a bit for more understanding.
Something leads me to believe that the DMA mask is 32 bits, but
given
that the behaviour is similar in both instances, I am unsure.
This isn't a critical issue right now. It can be figured out safely later.
I am now actually 100% positive the DMA mask is 32 bits.
By the way, it's an original X-Fi in this case (I have others to test with). lspci -vvv gives us:
05:01.0 Multimedia audio controller: Creative Labs SB X-Fi Subsystem: Creative Labs Device 0021 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (1000ns min, 1250ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at d200 [size=32] Region 1: Memory at f0000000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at ec000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000
Kernel is: Linux version 2.6.27 (nenolod@petrie) (gcc version 4.2.4 (Debian 4.2.4-2 +b1)) #1 SMP Sat Oct 11 11:59:08 CDT 2008
William
At Sat, 11 Oct 2008 13:04:02 -0500, William Pitcock wrote:
Hi,
On Sat, 2008-10-11 at 19:41 +0200, Takashi Iwai wrote:
Could you build with XXX_CONST_TIMER defined? This will disable the adaptive timer-resolution handling I added to the driver, which doesn't exist in OSS sbxfi code at all.
No change in behaviour. It survives a little longer, but then the system hardlocks... without me even touching the keyboard even.
This can be a spin deadlock I fixed today. Could you try the latest sound-unstable GIT or snapshot tarball?
Also, now the driver has "debug" module option. As default, it's 1, and the driver shows some debug messages. When it's 2, it shows more often, e.g. at each IRQ. When it's 3, it shows all register accesses.
The debug option can be changed even dynamically via sysfs. Write /sys/modules/snd_sbxfi/parameters/debug file as root, # echo 3 > /sys/modules/..../debug
Just a note before I go to bed :)
Takashi
At Sun, 12 Oct 2008 21:34:01 +0200, I wrote:
At Sat, 11 Oct 2008 13:04:02 -0500, William Pitcock wrote:
Hi,
On Sat, 2008-10-11 at 19:41 +0200, Takashi Iwai wrote:
Could you build with XXX_CONST_TIMER defined? This will disable the adaptive timer-resolution handling I added to the driver, which doesn't exist in OSS sbxfi code at all.
No change in behaviour. It survives a little longer, but then the system hardlocks... without me even touching the keyboard even.
This can be a spin deadlock I fixed today. Could you try the latest sound-unstable GIT or snapshot tarball?
FYI, that fix was also broken, and I forgot to push the fix of the fix. My bad.
It should have been fixed now.
You can check the latest git log via http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-unstable-2.6.git;a=sho...
Takashi
Takashi Iwai <tiwai <at> suse.de> writes:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi
I finally managed to play music over xmms with this driver. I needed to modify something, because most music is 44100Hz and the driver did not work with this rate.
61,62c61,62 < #undef XXX_48K_ONLY < #define XXX_CONT_RATE ---
#define XXX_48K_ONLY #undef XXX_CONT_RATE
529a530,532
case 44100: ratec = 0x4c; break;
It also needs to run in 48000Hz mode or else it will playback way to slow. I think this flag in ratec switches to 96KHz mode in the X-Fi, in windows this mode is only available in Audio creation mode, so it must be handled in a special way somehow.
Great work with the driver, finally I have sound under linux as creative's driver only oopsed the kernel for me :)
At Thu, 16 Oct 2008 12:03:41 +0000 (UTC), Jan Wolf wrote:
Takashi Iwai <tiwai <at> suse.de> writes:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi
I finally managed to play music over xmms with this driver. I needed to modify something, because most music is 44100Hz and the driver did not work with this rate.
61,62c61,62 < #undef XXX_48K_ONLY
< #define XXX_CONT_RATE
#define XXX_48K_ONLY #undef XXX_CONT_RATE
529a530,532
case 44100: ratec = 0x4c; break;It also needs to run in 48000Hz mode or else it will playback way to slow.
So, XXX_96K_ONLY doesn't work well?
I think this flag in ratec switches to 96KHz mode in the X-Fi, in windows this mode is only available in Audio creation mode, so it must be handled in a special way somehow.
Thanks, good to know ;)
And, which X-Fi model do you have? Please show the lspci -nv output, too.
Takashi
Takashi Iwai wrote:
At Thu, 16 Oct 2008 12:03:41 +0000 (UTC), Jan Wolf wrote:
Takashi Iwai <tiwai <at> suse.de> writes:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi
I finally managed to play music over xmms with this driver. I needed to modify something, because most music is 44100Hz and the driver did not work with this rate.
61,62c61,62 < #undef XXX_48K_ONLY
< #define XXX_CONT_RATE
#define XXX_48K_ONLY #undef XXX_CONT_RATE
529a530,532
case 44100: ratec = 0x4c; break;It also needs to run in 48000Hz mode or else it will playback way to slow.
So, XXX_96K_ONLY doesn't work well?
Interesting, XXX_96K_ONLY also works, just XXX_CONT_RATE doesn't.
I think this flag in ratec switches to 96KHz mode in the X-Fi, in windows this mode is only available in Audio creation mode, so it must be handled in a special way somehow.
Thanks, good to know ;)
It's just speculation on my part, but as I just played around with the flag it didn't seem to do anything, at least with 44100Hz input. Otherwise the code I patched in just makes sure ratec is set at all when playing back at 44100Hz, otherwise playback in xmms just hangs.
And, which X-Fi model do you have? Please show the lspci -nv output, too.
I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
And lspci outputs:
05:08.0 Multimedia audio controller [0401]: Creative Labs SB X-Fi [1102:0005] Subsystem: Creative Labs Device [1102:0022] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (1000ns min, 1250ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: I/O ports at b400 [size=32] Region 1: Memory at c5000000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at c0000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
Xarteras пишет:
Takashi Iwai wrote:
At Thu, 16 Oct 2008 12:03:41 +0000 (UTC), Jan Wolf wrote:
Takashi Iwai <tiwai <at> suse.de> writes:
Hi,
$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.
If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master
If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball.
(I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.)
The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script.
**NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible.
There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all.
Any test- (and better debugging-) reports are appreciated.
thanks,
Takashi
I finally managed to play music over xmms with this driver. I needed to modify something, because most music is 44100Hz and the driver did not work with this rate.
61,62c61,62 < #undef XXX_48K_ONLY
< #define XXX_CONT_RATE
#define XXX_48K_ONLY #undef XXX_CONT_RATE
529a530,532
case 44100: ratec = 0x4c; break;It also needs to run in 48000Hz mode or else it will playback way to slow.
So, XXX_96K_ONLY doesn't work well?
Interesting, XXX_96K_ONLY also works, just XXX_CONT_RATE doesn't.
I think this flag in ratec switches to 96KHz mode in the X-Fi, in windows this mode is only available in Audio creation mode, so it must be handled in a special way somehow.
Thanks, good to know ;)
It's just speculation on my part, but as I just played around with the flag it didn't seem to do anything, at least with 44100Hz input. Otherwise the code I patched in just makes sure ratec is set at all when playing back at 44100Hz, otherwise playback in xmms just hangs.
And, which X-Fi model do you have? Please show the lspci -nv output, too.
I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
And lspci outputs:
05:08.0 Multimedia audio controller [0401]: Creative Labs SB X-Fi [1102:0005] Subsystem: Creative Labs Device [1102:0022] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (1000ns min, 1250ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: I/O ports at b400 [size=32] Region 1: Memory at c5000000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at c0000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mAPME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
And, which X-Fi model do you have? Please show the lspci -nv output, too.
I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
Takashi
Takashi Iwai пишет:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
And, which X-Fi model do you have? Please show the lspci -nv output, too.
I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
Takashi
Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.
At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
And, which X-Fi model do you have? Please show the lspci -nv output, too.
I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
Takashi
Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.
Already fixed.
Takashi
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
And, which X-Fi model do you have? Please show the lspci -nv output, too.
I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
Takashi
Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.
Already fixed.
Takashi
In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)
At Thu, 16 Oct 2008 18:41:08 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
> And, which X-Fi model do you have? > Please show the lspci -nv output, too. > > > > I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
Takashi
Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.
Already fixed.
Takashi
In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)
Hmm, it seems broken for older kernels right now. The easy workaround is to pass --with-cards=sbxfi to configure.
Anyway, I'll fix it now.
thanks,
Takashi
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:41:08 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
>> And, which X-Fi model do you have? >> Please show the lspci -nv output, too. >> >> >> >> >> > I've got the X-Fi Elite Pro. > That's The one with the external In/Out box. > > Speaking of which, the headphone jack on it does not output a signal > yet, the signal only goes to line out. > > There's some relais on the card that seem to switch these, they click > multiple times with the windows driver and not all all with yours, I > think that's the reason :) > > > > Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
Takashi
Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.
Already fixed.
Takashi
In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)
Hmm, it seems broken for older kernels right now. The easy workaround is to pass --with-cards=sbxfi to configure.
Anyway, I'll fix it now.
thanks,
Takashi
Hey, man, this is cool! Plays just fine (volume ok, speed ok, no glitches) with 96000, 48000, 44100, 22050, 16/24 bit, Stereo and Mono!! I didn't change anything in the source code, so I don't use system timer. Yes!!
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:41:08 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
>> And, which X-Fi model do you have? >> Please show the lspci -nv output, too. >> >> >> >> >> > I've got the X-Fi Elite Pro. > That's The one with the external In/Out box. > > Speaking of which, the headphone jack on it does not output a signal > yet, the signal only goes to line out. > > There's some relais on the card that seem to switch these, they click > multiple times with the windows driver and not all all with yours, I > think that's the reason :) > > > > Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
Takashi
Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.
Already fixed.
Takashi
In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)
Hmm, it seems broken for older kernels right now. The easy workaround is to pass --with-cards=sbxfi to configure.
Anyway, I'll fix it now.
thanks,
Takashi
--Hey, man, this is cool! Plays just fine (volume ok, speed ok, no --glitches) with 96000, 48000, 44100, 22050, 16/24 bit, Stereo and --Mono!! --I didn't change anything in the source code, so I don't use system --timer. Yes!!
However oss (alsa-emulated) is unstable. I'll test more.
At Thu, 16 Oct 2008 19:00:16 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:41:08 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
>>> And, which X-Fi model do you have? >>> Please show the lspci -nv output, too. >>> >>> >>> >>> >>> >> I've got the X-Fi Elite Pro. >> That's The one with the external In/Out box. >> >> Speaking of which, the headphone jack on it does not output a signal >> yet, the signal only goes to line out. >> >> There's some relais on the card that seem to switch these, they click >> multiple times with the windows driver and not all all with yours, I >> think that's the reason :) >> >> >> >> > Original OSS driver doesn't output to external block also, so it > wouldn't be easy to make this support I think. > > > The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
Takashi
Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.
Already fixed.
Takashi
In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)
Hmm, it seems broken for older kernels right now. The easy workaround is to pass --with-cards=sbxfi to configure.
Anyway, I'll fix it now.
thanks,
Takashi
--Hey, man, this is cool! Plays just fine (volume ok, speed ok, no --glitches) with 96000, 48000, 44100, 22050, 16/24 bit, Stereo and --Mono!! --I didn't change anything in the source code, so I don't use system --timer. Yes!!
However oss (alsa-emulated) is unstable. I'll test more.
Could be due to 96kHz base-rate? Try base_rate=48000. If you get still problems, please show the kernel logs with debug=2.
BTW, the jack.c compile error should have been fixed now (hopefully). Let me know if you still have the build errors.
thanks,
Takashi
Takashi Iwai wrote:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
And, which X-Fi model do you have? Please show the lspci -nv output, too.
I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
I opened the external box for checking what's in there and noticed the headphone jack seems to have it's own dedicated second DAC (CS4392KZ), and audio interface receiver (CS8415A), so it could get a bit more complicated. I'll see if I can find out more about that.
Also I found the GPIO flags that switch the relais, but that's probably useless as long as their function is not known. (It's 0x04, 0x40, 0x200 and 0x1000).
Jan Wolf
Xarteras wrote:
Takashi Iwai wrote:
At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:
And, which X-Fi model do you have? Please show the lspci -nv output, too.
I've got the X-Fi Elite Pro. That's The one with the external In/Out box.
Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.
There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)
Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.
The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.
I opened the external box for checking what's in there and noticed the headphone jack seems to have it's own dedicated second DAC (CS4392KZ), and audio interface receiver (CS8415A), so it could get a bit more complicated. I'll see if I can find out more about that.
Also I found the GPIO flags that switch the relais, but that's probably useless as long as their function is not known. (It's 0x04, 0x40, 0x200 and 0x1000).
Jan Wolf
The relays are for padding. I.e. They switch in some attenuation for the mic or line inputs.
With the latest drivers I have random stutterings. I can't say if they occure regular, but they occure often. Sometimes every ~5 seconds, sometimes with more time between, somtimes less...
mplayer ---> Öffne Audiodecoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 160.0 kbit/10.42% (ratio: 20000->192000) Ausgewählter Audiocodec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) <---
Master and PCM channels are working.
kind regards Bjoern
At Wed, 22 Oct 2008 17:24:09 +0200, Bjoern Olausson wrote:
With the latest drivers I have random stutterings.
Is it a regression? I mean, did it ever work better than the latest version?
I can't say if they occure regular, but they occure often. Sometimes every ~5 seconds, sometimes with more time between, somtimes less...
mplayer ---> Öffne Audiodecoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 160.0 kbit/10.42% (ratio: 20000->192000) Ausgewählter Audiocodec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) <---
Master and PCM channels are working.
Do you see the problem except for MPlayer?
Does the patch change the behavior?
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 0a1c569..ebe2dee 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -1260,7 +1260,7 @@ static struct snd_pcm_hardware sbxfi_pcm_hardware = { .channels_min = 2, .channels_max = 2, .buffer_bytes_max = SBXFI_MAX_BUFFER, - .period_bytes_min = 64, + .period_bytes_min = 4096, .period_bytes_max = SBXFI_MAX_BUFFER, .periods_min = 1, .periods_max = 4096,
On Wed, Oct 22, 2008 at 17:26, Takashi Iwai tiwai@suse.de wrote:
At Wed, 22 Oct 2008 17:24:09 +0200, Bjoern Olausson wrote:
With the latest drivers I have random stutterings.
Is it a regression? I mean, did it ever work better than the latest version?
I cant remember for shure, sry.
I can't say if they occure regular, but they occure often. Sometimes every ~5 seconds, sometimes with more time between, somtimes less...
mplayer ---> Öffne Audiodecoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 160.0 kbit/10.42% (ratio: 20000->192000) Ausgewählter Audiocodec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) <---
Master and PCM channels are working.
Do you see the problem except for MPlayer?
No problems when using xine as backend or xine allone.
Does the patch change the behavior?
No, mplayer (using the smplayr GUI) behaves like I reportetd, xine works like bevor.
Just one thing changed: Running the same file with "mplayer file.avi" instead of "smplayer file.avi" now results in a crase. Without the patch I could at least run "mplayer file.avi" Now the system freezes or just restarts. No way to get mot info.
I'll revert the patch and check again.
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 0a1c569..ebe2dee 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -1260,7 +1260,7 @@ static struct snd_pcm_hardware sbxfi_pcm_hardware = { .channels_min = 2, .channels_max = 2, .buffer_bytes_max = SBXFI_MAX_BUFFER,
.period_bytes_min = 64,
.period_bytes_min = 4096, .period_bytes_max = SBXFI_MAX_BUFFER, .periods_min = 1, .periods_max = 4096,
On Wed, Oct 22, 2008 at 18:07, Bjoern Olausson lkmlist@gmail.com wrote:
No, mplayer (using the smplayr GUI) behaves like I reportetd, xine works like bevor.
Just one thing changed: Running the same file with "mplayer file.avi" instead of "smplayer file.avi" now results in a crase. Without the patch I could at least run "mplayer file.avi" Now the system freezes or just restarts. No way to get mot info.
I'll revert the patch and check again.
Mhh, I reverted the patch but mplayer still keeps freezing my system now... smplayer still works (with the stuttering) xine works fine.
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 0a1c569..ebe2dee 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -1260,7 +1260,7 @@ static struct snd_pcm_hardware sbxfi_pcm_hardware = { .channels_min = 2, .channels_max = 2, .buffer_bytes_max = SBXFI_MAX_BUFFER,
.period_bytes_min = 64,
.period_bytes_min = 4096, .period_bytes_max = SBXFI_MAX_BUFFER, .periods_min = 1, .periods_max = 4096,
Hi, there's an entry in oss hg repo that they made some improvements to oss_sbxfi, you might want to take a look.
alsa-driver-unstable-snapshot.tar.bz2 2864 KB 10/22/2008 04:21:00 PM
Fails to compile
13:42:51 [~/Desktop/alsa-driver-unstable] blub@freax $ ./configure --with-cards=sbxfi,hda-intel --with-debug=detect && make [...] In file included from /home/blub/Desktop/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2: /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: In function 'sbxfi_reprogram_timer': /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: 'SBXFI_TIMER_FRE' undeclared (first use in this function) /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: (Each undeclared identifier is reported only once /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: for each function it appears in.) make[4]: *** [/home/blub/Desktop/alsa-driver-unstable/pci/sbxfi/sbxfi.o] Error 1 make[3]: *** [/home/blub/Desktop/alsa-driver-unstable/pci/sbxfi] Error 2 make[2]: *** [/home/blub/Desktop/alsa-driver-unstable/pci] Error 2 make[1]: *** [_module_/home/blub/Desktop/alsa-driver-unstable] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.27' make: *** [compile] Error 2 13:43:33 [~/Desktop/alsa-driver-unstable]
Hi,
There is a "Q" missing from the end of SBXFI_TIMER_FRE in /alsa-kernel/pci/sbxfi/sbxfi.c
aplay works 48khz and 96khz, sounds perfect.
Takashi, I'd like to help testing if I can. Have a serial cable setup to capture console oopses. And it does crash whenever it sees alsa/pulse audio.
Jason
Bjoern Olausson wrote:
alsa-driver-unstable-snapshot.tar.bz2 2864 KB 10/22/2008 04:21:00 PM
Fails to compile
13:42:51 [~/Desktop/alsa-driver-unstable] blub@freax $ ./configure --with-cards=sbxfi,hda-intel --with-debug=detect && make [...] In file included from /home/blub/Desktop/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2: /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: In function 'sbxfi_reprogram_timer': /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: 'SBXFI_TIMER_FRE' undeclared (first use in this function) /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: (Each undeclared identifier is reported only once /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: for each function it appears in.) make[4]: *** [/home/blub/Desktop/alsa-driver-unstable/pci/sbxfi/sbxfi.o] Error 1 make[3]: *** [/home/blub/Desktop/alsa-driver-unstable/pci/sbxfi] Error 2 make[2]: *** [/home/blub/Desktop/alsa-driver-unstable/pci] Error 2 make[1]: *** [_module_/home/blub/Desktop/alsa-driver-unstable] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.27' make: *** [compile] Error 2 13:43:33 [~/Desktop/alsa-driver-unstable] _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Takashi Iwai wrote:
It'd be great if you can capture the whole Oops log. That was entirely missing for all the time.
Oops attached.
Caused when trying to use mplayer to play a wav that aplay played perfectly.
Happy to try anything to help.
Thanks, Jason
PS, the commands and output leading up to the oops are below.
[root@sentry ~]# modprobe snd_sbxfi [root@sentry ~]# aplay -Dplug:dmix:0 0_16_96.wav Playing WAVE '0_16_96.wav' : Signed 16 bit Little Endian, Rate 96000 Hz, Mono [root@sentry ~]# aplay -Dplug:dmix:0 wn.wav Playing WAVE 'wn.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo [root@sentry ~]# mplayer wn.wav MPlayer dev-SVN-r26936-4.3.0 (C) 2000-2008 MPlayer Team CPU: Intel(R) Celeron(R) CPU 2.53GHz (Family: 15, Model: 4, Stepping: 9) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control.
Playing wn.wav. Audio file file format detected. ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== AO: [pulse] Init failed: Connection refused *** PULSEAUDIO: Unable to connect: Connection refused *** Is your sound server running? *** See: http://www.pulseaudio.org/wiki/Troubleshooting [AO_ALSA] Playback open error: Connection refused
BUG: unable to handle kernel NULL pointer dereference at 00000038 IP: [<c0425ae4>] scheduler_tick+0x94/0x17a Oops: 0000 [#1] SMP Modules linked in: snd_sbxfi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc lp nfsd auth_rpcgss exportfs bridge bnep rfcomm l2cap bluetooth nfs lockd nfs_acl fuse sunrpc sr_mod cdrom dm_mirror dm_log dm_multipath dm_mod ppdev parport_pc parport floppy pcspkr i2c_i801 e100 mii sg iTCO_wdt iTCO_vendor_support usb_storage i915 drm i2c_algo_bit i2c_core pata_acpi ata_piix ata_generic libata sd_mod scsi_mod raid456 async_xor async_memcpy async_tx xor raid1 ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
Pid: 0, comm: Not tainted (2.6.26.5-45.fc9.i686 #1) EIP: 0060:[<c0425ae4>] EFLAGS: 00210046 CPU: 0 EIP is at scheduler_tick+0x94/0x17a EAX: c13fba80 EBX: 00000000 ECX: 00000000 EDX: dd9c9900 ESI: c13fba80 EDI: 00000010 EBP: dda80b4c ESP: dda80b30 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process (pid: 0, ti=dda80000 task=dd9c9900 task.ti=00000000) Stack: 000003ff dd9c9900 00000000 00000400 00000000 00000000 dd9c9900 dda80b60 c043102d c13f85a4 80fcf224 0000007c dda80b78 c0441c00 dda80be0 c13f85a4 7fffffff c13f8518 dda80b90 c043bc45 c13f8550 ffffffff 7fffffff c13f85a4 Call Trace: [<c043102d>] ? update_process_times+0x3d/0x49 [<c0441c00>] ? tick_sched_timer+0x6d/0xa5 [<c043bc45>] ? __run_hrtimer+0x4c/0x83 [<c043c618>] ? hrtimer_interrupt+0xef/0x152 [<c0414207>] ? smp_apic_timer_interrupt+0x69/0x7c [<c04056a8>] ? apic_timer_interrupt+0x28/0x30 [<e05a57ac>] ? sbxfi_pcm_hw_params+0xfc/0x18d [snd_sbxfi] [<e05167c7>] ? snd_pcm_hw_params+0xeb/0x2b0 [snd_pcm] [<e0516d34>] ? snd_pcm_common_ioctl1+0x269/0x1533 [snd_pcm] [<e051a8fc>] ? snd_pcm_hw_param_first+0x126/0x158 [snd_pcm] [<e05186b6>] ? snd_pcm_playback_ioctl1+0x360/0x377 [snd_pcm] [<e0518738>] ? snd_pcm_kernel_ioctl+0x38/0x60 [snd_pcm] [<e052b97a>] ? snd_pcm_oss_change_params+0x967/0xc89 [snd_pcm_oss] [<e052c418>] ? snd_pcm_oss_get_active_substream+0x29/0x70 [snd_pcm_oss] [<e052c4e9>] ? snd_pcm_oss_get_formats+0x11/0xba [snd_pcm_oss] [<c043c50d>] ? ktime_get+0x13/0x2f [<e052cf21>] ? snd_pcm_oss_ioctl+0x3b1/0xafe [snd_pcm_oss] [<e052cb70>] ? snd_pcm_oss_ioctl+0x0/0xafe [snd_pcm_oss] [<c048ffd6>] ? vfs_ioctl+0x22/0x69 [<c0490256>] ? do_vfs_ioctl+0x239/0x24c [<c04d54c9>] ? selinux_file_ioctl+0xa8/0xab [<c04902a9>] ? sys_ioctl+0x40/0x5b [<c0404c32>] ? syscall_call+0x7/0xb ======================= Code: fa 39 4d f0 0f 46 55 f0 0f af c1 88 d9 01 c2 d3 ea 89 54 9e 08 43 83 fb 05 74 04 01 ff eb d6 8b 45 e8 31 c9 8b 58 24 89 c2 89 f0 <ff> 53 38 f0 fe 06 8b 55 ec b8 80 2a 7a c0 8b 0c 95 80 23 75 c0 EIP: [<c0425ae4>] scheduler_tick+0x94/0x17a SS:ESP 0068:dda80b30 Kernel panic - not syncing: Fatal exception in interrupt
2008/10/23 Jason Harvey softdevice@jasonline.co.uk:
Takashi Iwai wrote:
It'd be great if you can capture the whole Oops log. That was entirely missing for all the time.
Oops attached.
Did you capture the Oops via a serial cabel? I had one attached too, but I never could capture an output... either the system rebooted or died without a message on the serial console...
Anything special you did to capture the oops?
Kind regards Bjoern
Bjoern Olausson wrote:
Did you capture the Oops via a serial cabel? I had one attached too, but I never could capture an output... either the system rebooted or died without a message on the serial console...
Anything special you did to capture the oops?
Yes, just a simple serial cable, no handshaking lines. Just added "console=ttyS0,57600n8 3" to the command line to stop enable the console and stop X I set the bitrate to 57600 to make things a bit faster. Using CuteCom to capture the output. Not had any instant reboots yet on the Intel based machine I am now using to test. On my dual Opteron machine it does reboot, I doubt there is enough time to squirt out an oops.
Regards, Jason
At Thu, 23 Oct 2008 12:53:02 +0100, Jason Harvey wrote:
Hi,
There is a "Q" missing from the end of SBXFI_TIMER_FRE in /alsa-kernel/pci/sbxfi/sbxfi.c
Yep. The fixed version is uploaded now.
aplay works 48khz and 96khz, sounds perfect.
Takashi, I'd like to help testing if I can. Have a serial cable setup to capture console oopses. And it does crash whenever it sees alsa/pulse audio.
It'd be great if you can capture the whole Oops log. That was entirely missing for all the time.
thanks,
Takashi
Jason
Bjoern Olausson wrote:
alsa-driver-unstable-snapshot.tar.bz2 2864 KB 10/22/2008 04:21:00 PM
Fails to compile
13:42:51 [~/Desktop/alsa-driver-unstable] blub@freax $ ./configure --with-cards=sbxfi,hda-intel --with-debug=detect && make [...] In file included from /home/blub/Desktop/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2: /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: In function 'sbxfi_reprogram_timer': /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: 'SBXFI_TIMER_FRE' undeclared (first use in this function) /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: (Each undeclared identifier is reported only once /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: for each function it appears in.) make[4]: *** [/home/blub/Desktop/alsa-driver-unstable/pci/sbxfi/sbxfi.o] Error 1 make[3]: *** [/home/blub/Desktop/alsa-driver-unstable/pci/sbxfi] Error 2 make[2]: *** [/home/blub/Desktop/alsa-driver-unstable/pci] Error 2 make[1]: *** [_module_/home/blub/Desktop/alsa-driver-unstable] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.27' make: *** [compile] Error 2 13:43:33 [~/Desktop/alsa-driver-unstable] _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Takashi Iwai wrote:
What is the last kernel message from sbxfi driver? Usually it prints some messages (as debug=1 as default).
I applied the patch and when trying "mplayer wn.wav" I consistently get the following message on the console
PANIC: double fault, gdt at c13f6000 [255 bytes]
nothing else, either reboots instantly or locks up.
In case you might find it of use I modprobed at debug=3 and ran dmesg before I ran mplayer. Output attached.
Regards, Jason
SBXFI: read(0) 0x1c6010 = 0x0 SBXFI: INIT HW SBXFI: read(0) 0x1c6070 = 0x104000 SBXFI: write(0) 0x1c6070 = 0x104000 SBXFI: write(0) 0x1c6070 = 0x104002 SBXFI: read(0) 0x1c6070 = 0x4002 SBXFI: read(0) 0x1c6070 = 0x104002 SBXFI: write(0) 0x1c6070 = 0x104aa3 SBXFI: read(0) 0x1c6070 = 0x104aa3 SBXFI: write(0) 0x1c6014 = 0x0 SBXFI: write(0) 0x1b102c = 0x0 SBXFI: read(0) 0x1b102c = 0x0 SBXFI: read(0) 0x1c6060 = 0xc08a0 SBXFI: write(0) 0x1c6060 = 0x1480a001 SBXFI: read(0) 0x1c6060 = 0x1000a001 SBXFI: read(0) 0x1c6060 = 0x1480a001 SBXFI: write(0) 0x1c6024 = 0x13fe SBXFI: write(0) 0x13b404 = 0x13 SBXFI: write(0) 0x13b408 = 0x200c01 SBXFI: DAOIMAP CLEAR SBXFI: write(0) 0x1c5000 = 0x0 SBXFI: write(0) 0x1c5004 = 0x0 SBXFI: write(0) 0x1c5008 = 0x0 SBXFI: write(0) 0x1c500c = 0x0 SBXFI: write(0) 0x1c5010 = 0x0 SBXFI: write(0) 0x1c5014 = 0x0 SBXFI: write(0) 0x1c5018 = 0x0 SBXFI: write(0) 0x1c501c = 0x0 SBXFI: write(0) 0x1c5020 = 0x0 SBXFI: write(0) 0x1c5024 = 0x0 SBXFI: write(0) 0x1c5028 = 0x0 SBXFI: write(0) 0x1c502c = 0x0 SBXFI: write(0) 0x1c5030 = 0x0 SBXFI: write(0) 0x1c5034 = 0x0 SBXFI: write(0) 0x1c5038 = 0x0 SBXFI: write(0) 0x1c503c = 0x0 SBXFI: write(0) 0x1c5040 = 0x0 SBXFI: write(0) 0x1c5044 = 0x0 SBXFI: write(0) 0x1c5048 = 0x0 SBXFI: write(0) 0x1c504c = 0x0 SBXFI: write(0) 0x1c5050 = 0x0 SBXFI: write(0) 0x1c5054 = 0x0 SBXFI: write(0) 0x1c5058 = 0x0 SBXFI: write(0) 0x1c505c = 0x0 SBXFI: write(0) 0x1c5060 = 0x0 SBXFI: write(0) 0x1c5064 = 0x0 SBXFI: write(0) 0x1c5068 = 0x0 SBXFI: write(0) 0x1c506c = 0x0 SBXFI: write(0) 0x1c5070 = 0x0 SBXFI: write(0) 0x1c5074 = 0x0 SBXFI: write(0) 0x1c5078 = 0x0 SBXFI: write(0) 0x1c507c = 0x0 SBXFI: write(0) 0x1c5080 = 0x0 SBXFI: write(0) 0x1c5084 = 0x0 SBXFI: write(0) 0x1c5088 = 0x0 SBXFI: write(0) 0x1c508c = 0x0 SBXFI: write(0) 0x1c5090 = 0x0 SBXFI: write(0) 0x1c5094 = 0x0 SBXFI: write(0) 0x1c5098 = 0x0 SBXFI: write(0) 0x1c509c = 0x0 SBXFI: write(0) 0x1c50a0 = 0x0 SBXFI: write(0) 0x1c50a4 = 0x0 SBXFI: write(0) 0x1c50a8 = 0x0 SBXFI: write(0) 0x1c50ac = 0x0 SBXFI: write(0) 0x1c50b0 = 0x0 SBXFI: write(0) 0x1c50b4 = 0x0 SBXFI: write(0) 0x1c50b8 = 0x0 SBXFI: write(0) 0x1c50bc = 0x0 SBXFI: write(0) 0x1c50c0 = 0x0 SBXFI: write(0) 0x1c50c4 = 0x0 SBXFI: write(0) 0x1c50c8 = 0x0 SBXFI: write(0) 0x1c50cc = 0x0 SBXFI: write(0) 0x1c50d0 = 0x0 SBXFI: write(0) 0x1c50d4 = 0x0 SBXFI: write(0) 0x1c50d8 = 0x0 SBXFI: write(0) 0x1c50dc = 0x0 SBXFI: write(0) 0x1c50e0 = 0x0 SBXFI: write(0) 0x1c50e4 = 0x0 SBXFI: write(0) 0x1c50e8 = 0x0 SBXFI: write(0) 0x1c50ec = 0x0 SBXFI: write(0) 0x1c50f0 = 0x0 SBXFI: write(0) 0x1c50f4 = 0x0 SBXFI: write(0) 0x1c50f8 = 0x0 SBXFI: write(0) 0x1c50fc = 0x0 SBXFI: write(0) 0x1c5100 = 0x0 SBXFI: write(0) 0x1c5104 = 0x0 SBXFI: write(0) 0x1c5108 = 0x0 SBXFI: write(0) 0x1c510c = 0x0 SBXFI: write(0) 0x1c5110 = 0x0 SBXFI: write(0) 0x1c5114 = 0x0 SBXFI: write(0) 0x1c5118 = 0x0 SBXFI: write(0) 0x1c511c = 0x0 SBXFI: write(0) 0x1c5120 = 0x0 SBXFI: write(0) 0x1c5124 = 0x0 SBXFI: write(0) 0x1c5128 = 0x0 SBXFI: write(0) 0x1c512c = 0x0 SBXFI: write(0) 0x1c5130 = 0x0 SBXFI: write(0) 0x1c5134 = 0x0 SBXFI: write(0) 0x1c5138 = 0x0 SBXFI: write(0) 0x1c513c = 0x0 SBXFI: INIT DAC SBXFI: read(0) 0x1c6020 = 0x8c00 SBXFI: write(0) 0x1c6020 = 0x8c02 SBXFI: SETUP I2S SBXFI: read(0) 0x1c5420 = 0x0 SBXFI: write(0) 0x1c5420 = 0x94040406 SBXFI: Setting TLB buffer page 0x1daff000 SBXFI: write(0) 0x13b004 = 0x1daff000 SBXFI: write(0) 0x13b000 = 0x0
Takashi Iwai wrote:
Anyway, could you try the patch below?
And, if it's reproducible (just try mplayer first without aplay), then you can add printk()'s and delays in each PCM callback to see where this happens, for example.
Running mplayer freezes the PC every time. strace confirms it is always at the same point. Tail end of the strace output is below.
SysReq keys dont respond once it has locked up.
Regards, Jason
futex(0x9a008ec, FUTEX_WAIT_PRIVATE, 1, NULL) = 0 write(2, "*** PULSEAUDIO: Unable to connec"..., 144*** PULSEAUDIO: Unable to connect: Connection refused *** Is your sound server running? *** See: http://www.pulseaudio.org/wiki/Troubleshooting ) = 144 futex(0x99fb050, FUTEX_UNLOCK_PI, 1331188) = 0 write(7, "W", 1) = 1 futex(0x99fb050, FUTEX_UNLOCK_PI, 1331188) = 0 munmap(0xb7b89000, 2097176) = 0 unlink("/dev/shm/pulse-shm-663979755") = 0 close(6) = 0 close(7) = 0 close(5) = 0 close(4) = 0 munmap(0x802000, 23856) = 0 write(2, "[AO_ALSA] Playback open error: C"..., 50[AO_ALSA] Playback open error: Connection refused ) = 50 open("/dev/dsp", O_WRONLY|O_NONBLOCK|O_LARGEFILE) = 4 fcntl64(4, F_SETFL, O_RDONLY) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 ioctl(4, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS
Takashi Iwai wrote:
One another thing I'm wondering is whether this happens only with OSS. What happens if you do like the following to disable the sample rate conversion?
# echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss
That works! Perfect stereo.
Playing wn.wav. Audio file file format detected. ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== AO: [pulse] Init failed: Connection refused *** PULSEAUDIO: Unable to connect: Connection refused *** Is your sound server running? *** See: http://www.pulseaudio.org/wiki/Troubleshooting [AO_ALSA] Playback open error: Connection refused AO: [oss] 96000Hz 2ch s16le (2 bytes per sample) Video: no video Starting playback... A: 101.2 (01:41.2) of 241.0 (04:01.0) 1.4%
Thanks, Jason
Takashi Iwai wrote:
Another patch to try is the one like below (on the top of the latest code). Any change with this?
Having trouble with 23 Oct unstable snapshot. Sorry, I might be doing something wrong!
Your patch applies cleanly but build fails on emu10k1. ./configure --with-cards=sbxfi still get error...
Regards, Jason
make[3]: Entering directory `/root/alsa-driver-unstable/pci/emu10k1'
make[3]: Warning: File `/root/alsa-driver-unstable/alsa-kernel/pci/emu10k1/Makefile' has modification time 5.5e+03 s in the future
copying file alsa-kernel/pci/emu10k1/emu10k1_main.c
patching file emu10k1_main.c
Hunk #3 FAILED at 673.
Hunk #4 succeeded at 1410 (offset 2 lines). Hunk #6 succeeded at 1764 with fuzz 1 (offset 3 lines). 1 out of 6 hunks FAILED -- saving rejects to file emu10k1_main.c.rej make[3]: *** [emu10k1_main.c] Error 1 make[3]: Leaving directory `/root/alsa-driver-unstable/pci/emu10k1'
make[2]: *** [prepare] Error 1
make[2]: Leaving directory `/root/alsa-driver-unstable/pci'
make[1]: *** [dep] Error 1
make[1]: Leaving directory `/root/alsa-driver-unstable'
make: *** [include/sndversions.h] Error 2
On Thu, Oct 23, 2008 at 17:37, Jason Harvey softdevice@jasonline.co.uk wrote:
Takashi Iwai wrote:
Another patch to try is the one like below (on the top of the latest code). Any change with this?
Having trouble with 23 Oct unstable snapshot. Sorry, I might be doing something wrong!
Your patch applies cleanly but build fails on emu10k1. ./configure --with-cards=sbxfi still get error...
Regards, Jason
Dito, same problem here
./configure --with-cards=sbxfi,hda-intel --with-debug=detect && make
make[3]: Entering directory `/home/blub/Desktop/alsa-driver-unstable/pci/emu10k1' copying file alsa-kernel/pci/emu10k1/emu10k1_main.c patching file emu10k1_main.c Hunk #3 FAILED at 673. Hunk #4 succeeded at 1410 (offset 2 lines). Hunk #5 succeeded at 1453 (offset 2 lines). Hunk #6 succeeded at 1764 with fuzz 1 (offset 3 lines). 1 out of 6 hunks FAILED -- saving rejects to file emu10k1_main.c.rej make[3]: *** [emu10k1_main.c] Error 1 make[3]: Leaving directory `/home/blub/Desktop/alsa-driver-unstable/pci/emu10k1' make[2]: *** [prepare] Error 1 make[2]: Leaving directory `/home/blub/Desktop/alsa-driver-unstable/pci' make[1]: *** [dep] Error 1 make[1]: Leaving directory `/home/blub/Desktop/alsa-driver-unstable' make: *** [include/sndversions.h] Error 2
At Thu, 23 Oct 2008 13:45:16 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
It'd be great if you can capture the whole Oops log. That was entirely missing for all the time.
Oops attached.
Thanks.
Caused when trying to use mplayer to play a wav that aplay played perfectly.
Happy to try anything to help.
What is the last kernel message from sbxfi driver? Usually it prints some messages (as debug=1 as default).
[root@sentry ~]# mplayer wn.wav MPlayer dev-SVN-r26936-4.3.0 (C) 2000-2008 MPlayer Team CPU: Intel(R) Celeron(R) CPU 2.53GHz (Family: 15, Model: 4, Stepping: 9) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control.
Playing wn.wav. Audio file file format detected. ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== AO: [pulse] Init failed: Connection refused *** PULSEAUDIO: Unable to connect: Connection refused *** Is your sound server running? *** See: http://www.pulseaudio.org/wiki/Troubleshooting [AO_ALSA] Playback open error: Connection refused
Hmm... connection refused? So it doesn't hang up at this moment yet.
The Oops shows somewhere in the hrtimer handler, so basically it's irrelevant from sbxfi itself. A possibility is that the driver made some memory corruption. Then it's a bit tough to catch.
Anyway, could you try the patch below?
And, if it's reproducible (just try mplayer first without aplay), then you can add printk()'s and delays in each PCM callback to see where this happens, for example.
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index dfdb64d..77558d1 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -914,11 +914,13 @@ static int sbxfi_setup_tlb(struct sbxfi *chip, struct sbxfi_port *port, } port->tlb_pages = pages;
+ LOG(1, "Allocated TLB at %d for %d pages (%d bytes)\n", + port->tlb_index, port->tlb_pages, bytes); pgtbl = (u32*)chip->tlb.area; pgtbl += port->tlb_index; for (p = 0; p < pages; p++, pgtbl++) *pgtbl = snd_pcm_sgbuf_get_addr(substream, p * SBXFI_PAGE_SIZE); - + LOG(1, "TLB setup done\n"); return 0; }
@@ -1354,16 +1356,11 @@ static int sbxfi_pcm_hw_params(struct snd_pcm_substream *substream, unsigned int bytes = params_buffer_bytes(hw_params); int err;
- err = snd_pcm_lib_malloc_pages(substream, bytes); - if (err < 0) - return err; - if (!err) - return 0; /* buffer unchanged */ sbxfi_clear_tlb(chip, port); - err = sbxfi_setup_tlb(chip, port, bytes); + err = snd_pcm_lib_malloc_pages(substream, bytes); if (err < 0) return err; - return 1; /* buffer changed */ + return sbxfi_setup_tlb(chip, port, bytes); }
static int sbxfi_pcm_hw_free(struct snd_pcm_substream *substream)
Takashi Iwai wrote:
Fixed and uploaded now. It might take some time until the changes are sync'ed.
Thanks, downloaded, patched fine. Attached dmesg_modprobe.txt shows output before playing anything.
No sound now using the oss workaround "echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss" Mplayer starts but doesn't increment shows 0% 0seconds etc etc, it can be interrupted ctrl-c, the PC remains functional, just no sound. dmesg_after.txt is the tail end of dmesg after interrupting mplayer, I trimmed it as the first couple seven lines repeat for about 330K in the original log :) Instant reboot when trying mplayer without the oss workaround.
aplay -Dplug:dmix:0 wn.wav still works. Trying mplayer after aplay freezes the machine with no output onto the console.
Thanks again, Jason
SBXFI: IRQ = 0x500 SBXFI: read(0) 0x1b0010 = 0x0 SBXFI: POINTER = 0x3e0 SBXFI: SET TIMER TICKS = 16 SBXFI: write(0) 0x1c6004 = 0xc010 SBXFI: write(0) 0x1c6010 = 0x500 SBXFI: read(0) 0x1c6010 = 0x500 SBXFI: IRQ = 0x500 SBXFI: read(0) 0x1b0010 = 0x0 SBXFI: POINTER = 0x3e0 SBXFI: SET TIMER TICKS = 16 SBXFI: write(0) 0x1c6004 = 0xc010 SBXFI: write(0) 0x1c6010 = 0x500 SBXFI: read(0) 0x1c6010 = 0x500 SBXFI: IRQ = 0x500 SBXFI: read(0) 0x1b0010 = 0x0 SBXFI: POINTER = 0x3e0 SBXFI: SET TIMER TICKS = 16 SBXFI: write(0) 0x1c6004 = 0xc010 SBXFI: write(0) 0x1c6010 = 0x500 ALSA /root/alsa-driver-unstable/acore/pcm_native.c:1498: playback drain error (DMA or IRQ trouble?) SBXFI: PLAY TRIGGER STOP SBXFI: read(0) 0x1b0000 = 0x0 SBXFI: write(0) 0x1b0000 = 0x0 SBXFI: read(0) 0x1b0100 = 0x0 SBXFI: write(0) 0x1b0100 = 0x0 SBXFI: PLAY UPDATE TIMER SBXFI: STOP EMU TIMER SBXFI: write(0) 0x1c6004 = 0x0 SBXFI: write(0) 0x1c6014 = 0x0 SBXFI: DAOIMAP CLEAR SBXFI: write(0) 0x1c5000 = 0x0 SBXFI: write(0) 0x1c5004 = 0x0 SBXFI: write(0) 0x1c5008 = 0x0 SBXFI: write(0) 0x1c500c = 0x0 SBXFI: write(0) 0x1c5010 = 0x0 SBXFI: write(0) 0x1c5014 = 0x0 SBXFI: write(0) 0x1c5018 = 0x0 SBXFI: write(0) 0x1c501c = 0x0 SBXFI: write(0) 0x1c5020 = 0x0 SBXFI: write(0) 0x1c5024 = 0x0 SBXFI: write(0) 0x1c5028 = 0x0 SBXFI: write(0) 0x1c502c = 0x0 SBXFI: write(0) 0x1c5030 = 0x0 SBXFI: write(0) 0x1c5034 = 0x0 SBXFI: write(0) 0x1c5038 = 0x0 SBXFI: write(0) 0x1c503c = 0x0 SBXFI: write(0) 0x1c5040 = 0x0 SBXFI: write(0) 0x1c5044 = 0x0 SBXFI: write(0) 0x1c5048 = 0x0 SBXFI: write(0) 0x1c504c = 0x0 SBXFI: write(0) 0x1c5050 = 0x0 SBXFI: write(0) 0x1c5054 = 0x0 SBXFI: write(0) 0x1c5058 = 0x0 SBXFI: write(0) 0x1c505c = 0x0 SBXFI: write(0) 0x1c5060 = 0x0 SBXFI: write(0) 0x1c5064 = 0x0 SBXFI: write(0) 0x1c5068 = 0x0 SBXFI: write(0) 0x1c506c = 0x0 SBXFI: write(0) 0x1c5070 = 0x0
SBXFI: write(0) 0x1c5074 = 0x0 SBXFI: write(0) 0x1c5078 = 0x0 SBXFI: write(0) 0x1c507c = 0x0 SBXFI: write(0) 0x1c5080 = 0x0 SBXFI: write(0) 0x1c5084 = 0x0 SBXFI: write(0) 0x1c5088 = 0x0 SBXFI: write(0) 0x1c508c = 0x0 SBXFI: write(0) 0x1c5090 = 0x0 SBXFI: write(0) 0x1c5094 = 0x0 SBXFI: write(0) 0x1c5098 = 0x0 SBXFI: write(0) 0x1c509c = 0x0 SBXFI: write(0) 0x1c50a0 = 0x0 SBXFI: write(0) 0x1c50a4 = 0x0 SBXFI: write(0) 0x1c50a8 = 0x0 SBXFI: write(0) 0x1c50ac = 0x0 SBXFI: write(0) 0x1c50b0 = 0x0 SBXFI: write(0) 0x1c50b4 = 0x0 SBXFI: write(0) 0x1c50b8 = 0x0 SBXFI: write(0) 0x1c50bc = 0x0 SBXFI: write(0) 0x1c50c0 = 0x0 SBXFI: write(0) 0x1c50c4 = 0x0 SBXFI: write(0) 0x1c50c8 = 0x0 SBXFI: write(0) 0x1c50cc = 0x0 SBXFI: write(0) 0x1c50d0 = 0x0 SBXFI: write(0) 0x1c50d4 = 0x0 SBXFI: write(0) 0x1c50d8 = 0x0 SBXFI: write(0) 0x1c50dc = 0x0 SBXFI: write(0) 0x1c50e0 = 0x0 SBXFI: write(0) 0x1c50e4 = 0x0 SBXFI: write(0) 0x1c50e8 = 0x0 SBXFI: write(0) 0x1c50ec = 0x0 SBXFI: write(0) 0x1c50f0 = 0x0 SBXFI: write(0) 0x1c50f4 = 0x0 SBXFI: write(0) 0x1c50f8 = 0x0 SBXFI: write(0) 0x1c50fc = 0x0 SBXFI: write(0) 0x1c5100 = 0x0 SBXFI: write(0) 0x1c5104 = 0x0 SBXFI: write(0) 0x1c5108 = 0x0 SBXFI: write(0) 0x1c510c = 0x0 SBXFI: write(0) 0x1c5110 = 0x0 SBXFI: write(0) 0x1c5114 = 0x0 SBXFI: write(0) 0x1c5118 = 0x0 SBXFI: write(0) 0x1c511c = 0x0 SBXFI: write(0) 0x1c5120 = 0x0 SBXFI: write(0) 0x1c5124 = 0x0 SBXFI: write(0) 0x1c5128 = 0x0 SBXFI: write(0) 0x1c512c = 0x0 SBXFI: write(0) 0x1c5130 = 0x0 SBXFI: write(0) 0x1c5134 = 0x0 SBXFI: write(0) 0x1c5138 = 0x0 SBXFI: write(0) 0x1c513c = 0x0 SBXFI: Release SRC 0 [root@sentry ~]#
SBXFI: read(0) 0x1c6010 = 0x0 SBXFI: INIT HW SBXFI: read(0) 0x1c6070 = 0x104000 SBXFI: write(0) 0x1c6070 = 0x104000 SBXFI: write(0) 0x1c6070 = 0x104002 SBXFI: read(0) 0x1c6070 = 0x4002 SBXFI: read(0) 0x1c6070 = 0x104002 SBXFI: write(0) 0x1c6070 = 0x104aa3 SBXFI: read(0) 0x1c6070 = 0x104aa3 SBXFI: write(0) 0x1c6014 = 0x0 SBXFI: write(0) 0x1b102c = 0x0 SBXFI: read(0) 0x1b102c = 0x0 SBXFI: read(0) 0x1c6060 = 0xc08a0 SBXFI: write(0) 0x1c6060 = 0x1480a001 SBXFI: read(0) 0x1c6060 = 0x1000a001 SBXFI: read(0) 0x1c6060 = 0x1480a001 SBXFI: write(0) 0x1c6024 = 0x13fe SBXFI: write(0) 0x13b404 = 0x13 SBXFI: write(0) 0x13b408 = 0x200c01 SBXFI: DAOIMAP CLEAR SBXFI: write(0) 0x1c5000 = 0x0 SBXFI: write(0) 0x1c5004 = 0x0 SBXFI: write(0) 0x1c5008 = 0x0 SBXFI: write(0) 0x1c500c = 0x0 SBXFI: write(0) 0x1c5010 = 0x0 SBXFI: write(0) 0x1c5014 = 0x0 SBXFI: write(0) 0x1c5018 = 0x0 SBXFI: write(0) 0x1c501c = 0x0 SBXFI: write(0) 0x1c5020 = 0x0 SBXFI: write(0) 0x1c5024 = 0x0 SBXFI: write(0) 0x1c5028 = 0x0 SBXFI: write(0) 0x1c502c = 0x0 SBXFI: write(0) 0x1c5030 = 0x0 SBXFI: write(0) 0x1c5034 = 0x0 SBXFI: write(0) 0x1c5038 = 0x0 SBXFI: write(0) 0x1c503c = 0x0 SBXFI: write(0) 0x1c5040 = 0x0 SBXFI: write(0) 0x1c5044 = 0x0 SBXFI: write(0) 0x1c5048 = 0x0 SBXFI: write(0) 0x1c504c = 0x0 SBXFI: write(0) 0x1c5050 = 0x0 SBXFI: write(0) 0x1c5054 = 0x0 SBXFI: write(0) 0x1c5058 = 0x0 SBXFI: write(0) 0x1c505c = 0x0 SBXFI: write(0) 0x1c5060 = 0x0 SBXFI: write(0) 0x1c5064 = 0x0 SBXFI: write(0) 0x1c5068 = 0x0 SBXFI: write(0) 0x1c506c = 0x0 SBXFI: write(0) 0x1c5070 = 0x0 SBXFI: write(0) 0x1c5074 = 0x0 SBXFI: write(0) 0x1c5078 = 0x0 SBXFI: write(0) 0x1c507c = 0x0 SBXFI: write(0) 0x1c5080 = 0x0 SBXFI: write(0) 0x1c5084 = 0x0 SBXFI: write(0) 0x1c5088 = 0x0 SBXFI: write(0) 0x1c508c = 0x0 SBXFI: write(0) 0x1c5090 = 0x0 SBXFI: write(0) 0x1c5094 = 0x0 SBXFI: write(0) 0x1c5098 = 0x0 SBXFI: write(0) 0x1c509c = 0x0 SBXFI: write(0) 0x1c50a0 = 0x0 SBXFI: write(0) 0x1c50a4 = 0x0 SBXFI: write(0) 0x1c50a8 = 0x0 SBXFI: write(0) 0x1c50ac = 0x0 SBXFI: write(0) 0x1c50b0 = 0x0 SBXFI: write(0) 0x1c50b4 = 0x0 SBXFI: write(0) 0x1c50b8 = 0x0 SBXFI: write(0) 0x1c50bc = 0x0 SBXFI: write(0) 0x1c50c0 = 0x0 SBXFI: write(0) 0x1c50c4 = 0x0 SBXFI: write(0) 0x1c50c8 = 0x0 SBXFI: write(0) 0x1c50cc = 0x0 SBXFI: write(0) 0x1c50d0 = 0x0 SBXFI: write(0) 0x1c50d4 = 0x0 SBXFI: write(0) 0x1c50d8 = 0x0 SBXFI: write(0) 0x1c50dc = 0x0 SBXFI: write(0) 0x1c50e0 = 0x0 SBXFI: write(0) 0x1c50e4 = 0x0 SBXFI: write(0) 0x1c50e8 = 0x0 SBXFI: write(0) 0x1c50ec = 0x0 SBXFI: write(0) 0x1c50f0 = 0x0 SBXFI: write(0) 0x1c50f4 = 0x0 SBXFI: write(0) 0x1c50f8 = 0x0 SBXFI: write(0) 0x1c50fc = 0x0 SBXFI: write(0) 0x1c5100 = 0x0 SBXFI: write(0) 0x1c5104 = 0x0 SBXFI: write(0) 0x1c5108 = 0x0 SBXFI: write(0) 0x1c510c = 0x0 SBXFI: write(0) 0x1c5110 = 0x0 SBXFI: write(0) 0x1c5114 = 0x0 SBXFI: write(0) 0x1c5118 = 0x0 SBXFI: write(0) 0x1c511c = 0x0 SBXFI: write(0) 0x1c5120 = 0x0 SBXFI: write(0) 0x1c5124 = 0x0 SBXFI: write(0) 0x1c5128 = 0x0 SBXFI: write(0) 0x1c512c = 0x0 SBXFI: write(0) 0x1c5130 = 0x0 SBXFI: write(0) 0x1c5134 = 0x0 SBXFI: write(0) 0x1c5138 = 0x0 SBXFI: write(0) 0x1c513c = 0x0 SBXFI: INIT DAC SBXFI: read(0) 0x1c6020 = 0x8c00 SBXFI: write(0) 0x1c6020 = 0x8c02 SBXFI: SETUP I2S SBXFI: read(0) 0x1c5420 = 0x0 SBXFI: write(0) 0x1c5420 = 0x94040406
At Thu, 23 Oct 2008 15:23:24 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
What is the last kernel message from sbxfi driver? Usually it prints some messages (as debug=1 as default).
I applied the patch and when trying "mplayer wn.wav" I consistently get the following message on the console
PANIC: double fault, gdt at c13f6000 [255 bytes]
nothing else, either reboots instantly or locks up.
In case you might find it of use I modprobed at debug=3 and ran dmesg before I ran mplayer. Output attached.
Thanks.
The last entries are:
SBXFI: Setting TLB buffer page 0x1daff000 SBXFI: write(0) 0x13b004 = 0x1daff000 SBXFI: write(0) 0x13b000 = 0x0
Hm, this smells like a buffer handling issue.
I updated the sbxfi driver code now, added mutex around the code handling TLB pages. Please give it a try.
Takashi
At Thu, 23 Oct 2008 19:07:40 +0200, I wrote:
At Thu, 23 Oct 2008 15:23:24 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
What is the last kernel message from sbxfi driver? Usually it prints some messages (as debug=1 as default).
I applied the patch and when trying "mplayer wn.wav" I consistently get the following message on the console
PANIC: double fault, gdt at c13f6000 [255 bytes]
nothing else, either reboots instantly or locks up.
In case you might find it of use I modprobed at debug=3 and ran dmesg before I ran mplayer. Output attached.
Thanks.
The last entries are:
SBXFI: Setting TLB buffer page 0x1daff000 SBXFI: write(0) 0x13b004 = 0x1daff000 SBXFI: write(0) 0x13b000 = 0x0
Hm, this smells like a buffer handling issue.
I updated the sbxfi driver code now, added mutex around the code handling TLB pages. Please give it a try.
Another patch to try is the one like below (on the top of the latest code). Any change with this?
thanks,
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 458294f..cbb56eb 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -603,10 +603,6 @@ static void sbxfi_capture_start(struct sbxfi *chip, struct sbxfi_port *port) /* slave */ ctrl = ratec; sbxfi_setup_src(chip, port->src[1], start, loop, 0x80, ctrl); -#if 0 /* XXX */ - /* Enable SRC input from Audio Ring */ - sbxfi_write(chip, SRC_MASTER_CTL, 0x1); -#endif }
static void sbxfi_capture_stop(struct sbxfi *chip, struct sbxfi_port *port) @@ -620,10 +616,6 @@ static void sbxfi_capture_stop(struct sbxfi *chip, struct sbxfi_port *port) val = sbxfi_read(chip, SRCCTL(port->src[1])); val &= ~0x0f; sbxfi_write(chip, SRCCTL(port->src[1]), val); -#if 0 /* XXX */ - /* Disable SRC inputs from Audio Ring */ - sbxfi_write(chip, SRC_MASTER_CTL, 0x0); -#endif }
/* some sync of reset sequence */ @@ -900,6 +892,8 @@ static void sbxfi_clear_tlb(struct sbxfi *chip, struct sbxfi_port *port) port->tlb_pages = 0; port->tlb_index = -1; if (!chip->used_pages) { + /* Disable SRC inputs from Audio Ring */ + sbxfi_write(chip, SRC_MASTER_CTL, 0x0); LOG(1, "Disabling TLB buffer\n"); sbxfi_write(chip, TRANS_TLB_PHY_ADDR_LO_0, 0); sbxfi_write(chip, TRANS_TLB_PHY_ADDR_HI_0, 0); @@ -938,6 +932,8 @@ static int sbxfi_setup_tlb(struct sbxfi *chip, struct sbxfi_port *port, sbxfi_write(chip, TRANS_TLB_PHY_ADDR_LO_0, (u32)chip->tlb.addr); sbxfi_write(chip, TRANS_TLB_PHY_ADDR_HI_0, upper_32_bits(chip->tlb.addr)); + /* Enable SRC input from Audio Ring */ + sbxfi_write(chip, SRC_MASTER_CTL, 0x1); } chip->used_pages += pages;
@@ -977,10 +973,6 @@ static struct sbxfi_port *sbxfi_port_alloc(struct sbxfi *chip, port->src[1] = src + 1; LOG(1, "Allocate SRC %d\n", src); spin_lock_irq(&chip->port_lock); - if (list_empty(&chip->port_list)) { - /* Enable SRC input from Audio Ring */ - sbxfi_write(chip, SRC_MASTER_CTL, 0x1); - } list_add(&port->list, &chip->port_list); spin_unlock_irq(&chip->port_lock); return port; @@ -992,10 +984,6 @@ static void sbxfi_port_free(struct sbxfi *chip, struct sbxfi_port *port) return; spin_lock_irq(&chip->port_lock); list_del(&port->list); - if (list_empty(&chip->port_list)) { - /* Disable SRC inputs from Audio Ring */ - sbxfi_write(chip, SRC_MASTER_CTL, 0x0); - } spin_unlock_irq(&chip->port_lock); LOG(1, "Release SRC %d\n", port->src[0]); bitmap_release_region(chip->src_bitmap, port->src[0], 1); @@ -1338,7 +1326,6 @@ static int sbxfi_playback_close(struct snd_pcm_substream *substream) { struct sbxfi *chip = snd_pcm_substream_chip(substream); struct sbxfi_port *port = substream->runtime->private_data; - sbxfi_cleanup_play_mapper(chip, port); sbxfi_port_free(chip, port); return 0; } @@ -1379,6 +1366,7 @@ static int sbxfi_pcm_hw_params(struct snd_pcm_substream *substream, unsigned int bytes = params_buffer_bytes(hw_params); int err;
+ sbxfi_cleanup_play_mapper(chip, port); sbxfi_clear_tlb(chip, port); err = snd_pcm_lib_malloc_pages(substream, bytes); if (err < 0) @@ -1396,6 +1384,7 @@ static int sbxfi_pcm_hw_free(struct snd_pcm_substream *substream) struct sbxfi *chip = snd_pcm_substream_chip(substream); struct sbxfi_port *port = substream->runtime->private_data;
+ sbxfi_cleanup_play_mapper(chip, port); sbxfi_clear_tlb(chip, port); return snd_pcm_lib_free_pages(substream); }
At Thu, 23 Oct 2008 19:15:26 +0200, I wrote:
At Thu, 23 Oct 2008 19:07:40 +0200, I wrote:
At Thu, 23 Oct 2008 15:23:24 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
What is the last kernel message from sbxfi driver? Usually it prints some messages (as debug=1 as default).
I applied the patch and when trying "mplayer wn.wav" I consistently get the following message on the console
PANIC: double fault, gdt at c13f6000 [255 bytes]
nothing else, either reboots instantly or locks up.
In case you might find it of use I modprobed at debug=3 and ran dmesg before I ran mplayer. Output attached.
Thanks.
The last entries are:
SBXFI: Setting TLB buffer page 0x1daff000 SBXFI: write(0) 0x13b004 = 0x1daff000 SBXFI: write(0) 0x13b000 = 0x0
Hm, this smells like a buffer handling issue.
I updated the sbxfi driver code now, added mutex around the code handling TLB pages. Please give it a try.
Another patch to try is the one like below (on the top of the latest code). Any change with this?
One another thing I'm wondering is whether this happens only with OSS. What happens if you do like the following to disable the sample rate conversion?
# echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss
Takashi
Takashi Iwai wrote:
At Thu, 23 Oct 2008 17:23:22 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
Fixed and uploaded now. It might take some time until the changes are sync'ed.
Thanks, downloaded, patched fine. Attached dmesg_modprobe.txt shows output before playing anything.
No sound now using the oss workaround "echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss" Mplayer starts but doesn't increment shows 0% 0seconds etc etc, it can be interrupted ctrl-c, the PC remains functional, just no sound. dmesg_after.txt is the tail end of dmesg after interrupting mplayer, I trimmed it as the first couple seven lines repeat for about 330K in the original log :) Instant reboot when trying mplayer without the oss workaround.
OK, so the patch doesn't help, and it brings another problem. What about debug=2? This will give much less log, I guess.
debug=2 is still too big to see the start of playback. If I can get the buffer big enough to find the beginning I'll post it :)
aplay -Dplug:dmix:0 wn.wav still works. Trying mplayer after aplay freezes the machine with no output onto the console.
Even with OSS proc hack?
Yes, if I aplay first it locks up entirely when I issue OSS proc hack then run mplayer. Without running aplay I can get a dmesg but mplayer makes no sound. I've put the debug=1 output along with the commands etc below.
Regards, Jason
[root@sentry ~]# modprobe snd_sbxfi debug=1 [root@sentry ~]# dmesg ACPI: PCI Interrupt 0000:04:01.0[A] -> GSI 22 (level, low) -> IRQ 22 SBXFI: INIT HW
SBXFI: INIT DAC
SBXFI: SETUP I2S
[root@sentry ~]# echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss [root@sentry ~]# mplayer wn.wav MPlayer dev-SVN-r26936-4.3.0 (C) 2000-2008 MPlayer Team CPU: Intel(R) Celeron(R) CPU 2.53GHz (Family: 15, Model: 4, Stepping: 9) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control.
Playing wn.wav. Audio file file format detected. ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== AO: [pulse] Init failed: Connection refused *** PULSEAUDIO: Unable to connect: Connection refused *** Is your sound server running? *** See: http://www.pulseaudio.org/wiki/Troubleshooting [AO_ALSA] Playback open error: Connection refused AO: [oss] 96000Hz 2ch s16le (2 bytes per sample) Video: no video Starting playback... A: 0.0 (00.0) of 241.0 (04:01.0) ??,?%
MPlayer interrupted by signal 2 in module: play_audio
MPlayer interrupted by signal 2 in module: play_audio [root@sentry ~]# dmesg ACPI: PCI Interrupt 0000:04:01.0[A] -> GSI 22 (level, low) -> IRQ 22 SBXFI: INIT HW SBXFI: INIT DAC SBXFI: SETUP I2S SBXFI: Allocate SRC 0 SBXFI: allocated TLB at 0 for 16 pages SBXFI: Setting TLB buffer page 0x15a2c000 SBXFI: release TLB at 0 for 16 pages SBXFI: Disabling TLB buffer SBXFI: PLAYBACK PREPARE: rate=96000, period_size=1024, buffer_size=16384 SBXFI: Pitch [0:fa6] = 0x1000000 SBXFI: Pitch [80:7a6] = 0x1000000 SBXFI: Pitch [1:fb6] = 0x1000000 SBXFI: Pitch [81:7b6] = 0x1000000 SBXFI: Amp [00:0001] = 0x555 SBXFI: Amp [80:0801] = 0x555 SBXFI: Amp [01:0011] = 0x555 SBXFI: Amp [81:0811] = 0x555 SBXFI: PLAY TRIGGER START SBXFI: PLAY UPDATE TIMER ALSA /root/alsa-driver-unstable/acore/pcm_native.c:1498: playback drain error (DMA or IRQ trouble?) SBXFI: PLAY TRIGGER STOP SBXFI: PLAY UPDATE TIMER SBXFI: Release SRC 0 [root@sentry ~]#
At Thu, 23 Oct 2008 16:31:56 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
One another thing I'm wondering is whether this happens only with OSS. What happens if you do like the following to disable the sample rate conversion?
# echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss
That works! Perfect stereo.
Bah, then this sounds like a bug in OSS emulation code? Hmmm, now need to dig into that old crap...
thanks,
Takashi
At Thu, 23 Oct 2008 16:37:10 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
Another patch to try is the one like below (on the top of the latest code). Any change with this?
Having trouble with 23 Oct unstable snapshot. Sorry, I might be doing something wrong!
My bad. The patch for emu10k1 in alsa-driver tree must be updated, too. Will fix now.
Takashi
At Thu, 23 Oct 2008 19:44:05 +0200, I wrote:
At Thu, 23 Oct 2008 16:37:10 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
Another patch to try is the one like below (on the top of the latest code). Any change with this?
Having trouble with 23 Oct unstable snapshot. Sorry, I might be doing something wrong!
My bad. The patch for emu10k1 in alsa-driver tree must be updated, too. Will fix now.
Fixed and uploaded now. It might take some time until the changes are sync'ed.
Takashi
At Thu, 23 Oct 2008 17:23:22 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
Fixed and uploaded now. It might take some time until the changes are sync'ed.
Thanks, downloaded, patched fine. Attached dmesg_modprobe.txt shows output before playing anything.
No sound now using the oss workaround "echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss" Mplayer starts but doesn't increment shows 0% 0seconds etc etc, it can be interrupted ctrl-c, the PC remains functional, just no sound. dmesg_after.txt is the tail end of dmesg after interrupting mplayer, I trimmed it as the first couple seven lines repeat for about 330K in the original log :) Instant reboot when trying mplayer without the oss workaround.
OK, so the patch doesn't help, and it brings another problem. What about debug=2? This will give much less log, I guess.
aplay -Dplug:dmix:0 wn.wav still works. Trying mplayer after aplay freezes the machine with no output onto the console.
Even with OSS proc hack?
thanks,
Takashi
Takashi Iwai wrote:
Just to be sure: is it the driver with my patch or without the patch? The patch seems broken anyway, so abandon it, and check only without the patch from now on.
Have reverted to unpatched version, now logging kernel messages to a file. The attached is the output for debug=2 from running the mplayer with the oss proc fix. WARNING... the gzip expands to 4.5MB, which explains the overflow on the dmesg ring buffer. But only the first hundred lines and last ten are different, the rest are all the same as far as I could see.
The only things I noticed that does change is that the repeated lines start like this :-
Oct 23 20:45:28 sentry kernel: SBXFI: IRQ = 0x500 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: SET TIMER TICKS = 16 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0
And that the pattern changes after a short time dropping one of the POINTER lines. Screen output below to show commands used.
Regards, Jason
[root@sentry alsa-driver-unstable]# modprobe snd_sbxfi debug=2 [root@sentry alsa-driver-unstable]# cat /var/log/kernel Oct 23 20:44:00 sentry kernel: imklog 3.18.1, log source = /proc/kmsg started. Oct 23 20:44:47 sentry kernel: ACPI: PCI Interrupt 0000:04:01.0[A] -> GSI 22 (level, low) -> IRQ 22 Oct 23 20:44:47 sentry kernel: SBXFI: INIT HW Oct 23 20:44:47 sentry kernel: SBXFI: DAOIMAP CLEAR Oct 23 20:44:47 sentry kernel: SBXFI: INIT DAC Oct 23 20:44:47 sentry kernel: SBXFI: SETUP I2S [root@sentry alsa-driver-unstable]# echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss [root@sentry alsa-driver-unstable]# cd .. [root@sentry ~]# mplayer wn.wav MPlayer dev-SVN-r26936-4.3.0 (C) 2000-2008 MPlayer Team CPU: Intel(R) Celeron(R) CPU 2.53GHz (Family: 15, Model: 4, Stepping: 9) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control.
Playing wn.wav. Audio file file format detected. ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) ========================================================================== AO: [pulse] Init failed: Connection refused *** PULSEAUDIO: Unable to connect: Connection refused *** Is your sound server running? *** See: http://www.pulseaudio.org/wiki/Troubleshooting [AO_ALSA] Playback open error: Connection refused AO: [oss] 96000Hz 2ch s16le (2 bytes per sample) Video: no video Starting playback... A: 0.0 (00.0) of 241.0 (04:01.0) ??,?%
MPlayer interrupted by signal 2 in module: play_audio
MPlayer interrupted by signal 2 in module: play_audio [root@sentry ~]# cat /var/log/kernel |more Oct 23 20:44:00 sentry kernel: imklog 3.18.1, log source = /proc/kmsg started. Oct 23 20:44:47 sentry kernel: ACPI: PCI Interrupt 0000:04:01.0[A] -> GSI 22 (level, low) -> IRQ 22 Oct 23 20:44:47 sentry kernel: SBXFI: INIT HW Oct 23 20:44:47 sentry kernel: SBXFI: DAOIMAP CLEAR Oct 23 20:44:47 sentry kernel: SBXFI: INIT DAC Oct 23 20:44:47 sentry kernel: SBXFI: SETUP I2S Oct 23 20:45:28 sentry kernel: SBXFI: Allocate SRC 0 Oct 23 20:45:28 sentry kernel: SBXFI: allocated TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Setting TLB buffer page 0x1304a000 Oct 23 20:45:28 sentry kernel: SBXFI: release TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Disabling TLB buffer Oct 23 20:45:28 sentry kernel: SBXFI: PLAYBACK PREPARE: rate=96000, period_size=1024, buffer_size=16384 Oct 23 20:45:28 sentry kernel: SBXFI: Pitch [0:fa6] = 0x1000000 Oct 23 20:45:28 sentry kernel: SBXFI: Pitch [80:7a6] = 0x1000000 Oct 23 20:45:28 sentry kernel: SBXFI: Pitch [1:fb6] = 0x1000000 Oct 23 20:45:28 sentry kernel: SBXFI: Pitch [81:7b6] = 0x1000000 Oct 23 20:45:28 sentry kernel: SBXFI: Amp [00:0001] = 0x555 Oct 23 20:45:28 sentry kernel: SBXFI: Amp [80:0801] = 0x555 Oct 23 20:45:28 sentry kernel: SBXFI: Amp [01:0011] = 0x555 Oct 23 20:45:28 sentry kernel: SBXFI: Amp [81:0811] = 0x555 Oct 23 20:45:28 sentry kernel: SBXFI: DAOIMAP CLEAR Oct 23 20:45:28 sentry kernel: SBXFI: PLAY TRIGGER START Oct 23 20:45:28 sentry kernel: SBXFI: PLAY UPDATE TIMER Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: SET TIMER TICKS = 16 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: IRQ = 0x500 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: SET TIMER TICKS = 16 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0
At Thu, 23 Oct 2008 18:32:19 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
At Thu, 23 Oct 2008 17:23:22 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
Fixed and uploaded now. It might take some time until the changes are sync'ed.
Thanks, downloaded, patched fine. Attached dmesg_modprobe.txt shows output before playing anything.
No sound now using the oss workaround "echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss" Mplayer starts but doesn't increment shows 0% 0seconds etc etc, it can be interrupted ctrl-c, the PC remains functional, just no sound. dmesg_after.txt is the tail end of dmesg after interrupting mplayer, I trimmed it as the first couple seven lines repeat for about 330K in the original log :) Instant reboot when trying mplayer without the oss workaround.
OK, so the patch doesn't help, and it brings another problem. What about debug=2? This will give much less log, I guess.
debug=2 is still too big to see the start of playback. If I can get the buffer big enough to find the beginning I'll post it :)
That'll be good.
aplay -Dplug:dmix:0 wn.wav still works. Trying mplayer after aplay freezes the machine with no output onto the console.
Even with OSS proc hack?
Yes, if I aplay first it locks up entirely when I issue OSS proc hack then run mplayer. Without running aplay I can get a dmesg but mplayer makes no sound. I've put the debug=1 output along with the commands etc below.
Just to be sure: is it the driver with my patch or without the patch? The patch seems broken anyway, so abandon it, and check only without the patch from now on.
thanks,
Takashi
Takashi Iwai wrote:
Thanks. I guess the problem wa
Oct 23 20:45:28 sentry kernel: SBXFI: Allocate SRC 0 Oct 23 20:45:28 sentry kernel: SBXFI: allocated TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Setting TLB buffer page 0x1304a000 Oct 23 20:45:28 sentry kernel: SBXFI: release TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Disabling TLB buffer Oct 23 20:45:28 sentry kernel: SBXFI: PLAYBACK PREPARE: rate=96000, period_size=1024, buffer_size=16384
So the stream is started at the state where the TLB is cleared. The fix patch is below (and I already committed it).
Takashi
Yes that has fixed it. Tested with mplayer (still needs oss proc fix) and aplay. Both sounded fine.
Jason
At Thu, 23 Oct 2008 21:17:01 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
Just to be sure: is it the driver with my patch or without the patch? The patch seems broken anyway, so abandon it, and check only without the patch from now on.
Have reverted to unpatched version, now logging kernel messages to a file. The attached is the output for debug=2 from running the mplayer with the oss proc fix. WARNING... the gzip expands to 4.5MB, which explains the overflow on the dmesg ring buffer. But only the first hundred lines and last ten are different, the rest are all the same as far as I could see.
The only things I noticed that does change is that the repeated lines start like this :-
Oct 23 20:45:28 sentry kernel: SBXFI: IRQ = 0x500 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: SET TIMER TICKS = 16 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0 Oct 23 20:45:28 sentry kernel: SBXFI: POINTER = 0x3e0
And that the pattern changes after a short time dropping one of the POINTER lines. Screen output below to show commands used.
Thanks. I guess the problem was
Oct 23 20:45:28 sentry kernel: SBXFI: Allocate SRC 0 Oct 23 20:45:28 sentry kernel: SBXFI: allocated TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Setting TLB buffer page 0x1304a000 Oct 23 20:45:28 sentry kernel: SBXFI: release TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Disabling TLB buffer Oct 23 20:45:28 sentry kernel: SBXFI: PLAYBACK PREPARE: rate=96000, period_size=1024, buffer_size=16384
So the stream is started at the state where the TLB is cleared. The fix patch is below (and I already committed it).
Takashi
commit 9fc82bbe4ca9142cf2ae5db64eefaabc10e7f071 Author: Takashi Iwai tiwai@suse.de Date: Fri Oct 24 10:35:03 2008 +0200
sbxfi - Fix multiple hw_params calls
The last change seems breaking the case of multiple hw_params calls. Although the TLB is cleared unconditionally beforehand, it's not re-asssigned because snd_pcm_lib_malloc_pages() returns 0. Now, call sbxfi_setup_tlb() unconditionally, too.
Signed-off-by: Takashi Iwai tiwai@suse.de
--- diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 458294f..e268413 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -1383,12 +1383,7 @@ static int sbxfi_pcm_hw_params(struct snd_pcm_substream *substream, err = snd_pcm_lib_malloc_pages(substream, bytes); if (err < 0) return err; - if (!err) - return 0; /* buffer unchanged */ - err = sbxfi_setup_tlb(chip, port, bytes); - if (err < 0) - return err; - return 1; /* buffer changed */ + return sbxfi_setup_tlb(chip, port, bytes); }
static int sbxfi_pcm_hw_free(struct snd_pcm_substream *substream)
Takashi Iwai wrote:
At Fri, 24 Oct 2008 08:56:47 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
Thanks. I guess the problem wa
Oct 23 20:45:28 sentry kernel: SBXFI: Allocate SRC 0 Oct 23 20:45:28 sentry kernel: SBXFI: allocated TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Setting TLB buffer page 0x1304a000 Oct 23 20:45:28 sentry kernel: SBXFI: release TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Disabling TLB buffer Oct 23 20:45:28 sentry kernel: SBXFI: PLAYBACK PREPARE: rate=96000, period_size=1024, buffer_size=16384
So the stream is started at the state where the TLB is cleared. The fix patch is below (and I already committed it).
Takashi
Yes that has fixed it. Tested with mplayer (still needs oss proc fix) and aplay. Both sounded fine.
Thanks for quick checking.
So, the mplayer problem still exists - supposedly the same symptom? I'll take a look at OSS emulation code later.
Yes, mplayer without the proc oss fix gives an instant reboots with nothing on the console.
Thank you for your heroic work without any xfi hardware!
Jason
At Fri, 24 Oct 2008 08:56:47 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
Thanks. I guess the problem wa
Oct 23 20:45:28 sentry kernel: SBXFI: Allocate SRC 0 Oct 23 20:45:28 sentry kernel: SBXFI: allocated TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Setting TLB buffer page 0x1304a000 Oct 23 20:45:28 sentry kernel: SBXFI: release TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Disabling TLB buffer Oct 23 20:45:28 sentry kernel: SBXFI: PLAYBACK PREPARE: rate=96000, period_size=1024, buffer_size=16384
So the stream is started at the state where the TLB is cleared. The fix patch is below (and I already committed it).
Takashi
Yes that has fixed it. Tested with mplayer (still needs oss proc fix) and aplay. Both sounded fine.
Thanks for quick checking.
So, the mplayer problem still exists - supposedly the same symptom? I'll take a look at OSS emulation code later.
Takashi
I think I found a bug in the driver, which at least for me was responsible for the crashes with pulseaudio.
A little backstory:
I have a Fedora 8 System with an SB X-Fi installed and of course no sound. I didn't want to replace the entire ALSA driver, so I just took the files sbxfi.c and emu20k1-regs.h from the unstable sources, wrote a small spec-file and am now at a point where I can just "rpm -i" the driver as a dkms package and just modprobe the driver.
After that "speaker-test -D hw -c 2 -r 96000 -t sine" works just fine, but as soon as pulseaudio is started my System froze.
The bug I think I found is in the get_xfi_order function. As long as pages actually is a power of two it works correctly. But if pages isn't a power of two it should round up, but it rounds down. As a result I believe this screws up sbxfi_alloc_tlb_pages.
After a small modification to get_xfi_order:
--- /tmp/sbxfi.c 2008-10-25 14:51:55.000000000 +0200 +++ sbxfi.c 2008-10-25 14:03:48.000000000 +0200 @@ -851,11 +851,12 @@ /* get the order of pages (power-of-two) */ static int get_xfi_order(unsigned int pages) { - int order = -1; - do { + int order = 0; + pages--; + while(pages){ pages >>= 1; order++; - } while (pages); + } return order; }
the driver started working with pulseaudio, it doesn't crash, and I even get sound though it still is a bit distorted.
At Sat, 25 Oct 2008 15:06:52 +0200, Thomas Scheunemann wrote:
I think I found a bug in the driver, which at least for me was responsible for the crashes with pulseaudio.
A little backstory:
I have a Fedora 8 System with an SB X-Fi installed and of course no sound. I didn't want to replace the entire ALSA driver, so I just took the files sbxfi.c and emu20k1-regs.h from the unstable sources, wrote a small spec-file and am now at a point where I can just "rpm -i" the driver as a dkms package and just modprobe the driver.
After that "speaker-test -D hw -c 2 -r 96000 -t sine" works just fine, but as soon as pulseaudio is started my System froze.
The bug I think I found is in the get_xfi_order function. As long as pages actually is a power of two it works correctly. But if pages isn't a power of two it should round up, but it rounds down. As a result I believe this screws up sbxfi_alloc_tlb_pages.
After a small modification to get_xfi_order:
Thanks for the patch. Yeah, I found the very same problem in this morning, but I couldn't update the repo and snapshot until now due to the server crash.
My solution is to use roundup_pow_of_two() instead of the own funciton. This should work better in general.
Anyway, I updated the repo (and rebased, sorry), updated the snapshot, too.
thanks,
Takashi
--- /tmp/sbxfi.c 2008-10-25 14:51:55.000000000 +0200 +++ sbxfi.c 2008-10-25 14:03:48.000000000 +0200 @@ -851,11 +851,12 @@ /* get the order of pages (power-of-two) */ static int get_xfi_order(unsigned int pages) {
- int order = -1;
- do {
- int order = 0;
- pages--;
- while(pages){ pages >>= 1; order++;
- } while (pages);
- } return order;
}
the driver started working with pulseaudio, it doesn't crash, and I even get sound though it still is a bit distorted.
My solution is to use roundup_pow_of_two() instead of the own funciton. This should work better in general.
I certainly agree that it is better to use an already defined function instead of reinventing the wheel.
Anyway, I updated the repo (and rebased, sorry), updated the snapshot, too.
But this new version causes an immediate reboot on my machine even with the previously working speaker-test. If I interpret linux/log2.h correctly the desired function should be order_base_2 instead of roundup_pow_of_two. At least it works for me after that exchange.
At Sat, 25 Oct 2008 21:42:55 +0200, Thomas Scheunemann wrote:
My solution is to use roundup_pow_of_two() instead of the own funciton. This should work better in general.
I certainly agree that it is better to use an already defined function instead of reinventing the wheel.
Anyway, I updated the repo (and rebased, sorry), updated the snapshot, too.
But this new version causes an immediate reboot on my machine even with the previously working speaker-test. If I interpret linux/log2.h correctly the desired function should be order_base_2 instead of roundup_pow_of_two. At least it works for me after that exchange.
Oh my. You're right, it must be order_base_2(), of course. I was too hurry to fix a bug after the server crash :)
Now fixed and updated. Thanks!
Takashi
Takashi Iwai wrote:
At Sat, 25 Oct 2008 21:42:55 +0200, Thomas Scheunemann wrote:
My solution is to use roundup_pow_of_two() instead of the own funciton. This should work better in general.
I certainly agree that it is better to use an already defined function instead of reinventing the wheel.
Anyway, I updated the repo (and rebased, sorry), updated the snapshot, too.
But this new version causes an immediate reboot on my machine even with the previously working speaker-test. If I interpret linux/log2.h correctly the desired function should be order_base_2 instead of roundup_pow_of_two. At least it works for me after that exchange.
Oh my. You're right, it must be order_base_2(), of course. I was too hurry to fix a bug after the server crash :)
Now fixed and updated. Thanks!
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix. aplay still works but only with dmix. Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption. Machine did not crash at any point!
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
Jason
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy.. All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
kind regards Bjoern
Bjoern Olausson пишет:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy.. All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Tried the latest driver. All is fine (haven't tested recording however) except pulseaudio (doesn't work) and wine (sound is mega-glitchy, possibly because of strange period and buffer sizes it uses: period=544, buffer=8704). System is stable. OSS works fine.
Bjoern Olausson пишет:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy.. All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--Tried the latest driver. --All is fine (haven't tested recording however) except pulseaudio --(doesn't work) and wine (sound is mega-glitchy, possibly because of --strange period and buffer sizes it uses: period=544, buffer=8704). --System is stable. OSS works fine.
Also dmix causes horrible glitches everywhere. Was anyone able to make good dmix config?
Bjoern Olausson пишет:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy.. All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--Tried the latest driver. --All is fine (haven't tested recording however) except pulseaudio --(doesn't work) and wine (sound is mega-glitchy, possibly because of --strange period and buffer sizes it uses: period=544, buffer=8704). --System is stable. OSS works fine.
--Also dmix causes horrible glitches everywhere. Was anyone able to make --good dmix config?
Hmmm.. Looks like it is not dmix fault. wine requested something of driver that caused all sound to be glitchy until driver is reloaded. dmesg output with debug=3 is attached. Here's some wine output: fixme:wave:ALSA_ComputeCaps Device has a minimum of 2 channels fixme:wave:ALSA_ComputeCaps Device has a minimum of 2 channels fixme:wtsapi:WTSRegisterSessionNotification Stub 0x1004e 0x00000000 fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x1ac8c8,0x1ad118): stub fixme:dsalsa:CheckXRUN Unhandled state: 0 mixer.c:305: DSOUND_BufPtrDiff: Assertion `ptr2 < buflen' failed. wine: Assertion failed at address 0x60000812 (thread 001c), starting debugger... Unhandled exception: assertion failed in 32-bit code (0x60000812). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:60000812 ESP:7db9e740 EBP:7db9e74c EFLAGS:00200206( - 00 - -IP1) EAX:00000000 EBX:00001605 ECX:0000161a EDX:00000006 ESI:602a607a EDI:602d2ff4 Stack dump: 0x7db9e740: 60198660 602d2ff4 7db9e86c 7db9e874 0x7db9e750: 6019a028 00000006 7db9e7ec 00000000 0x7db9e760: 602d2ff4 00000043 7d394298 00000068 0x7db9e770: 601db11f 7db9e7b0 7d3942a0 7d3942a0 0x7db9e780: 601ac78b 602d2ff4 00000043 7d3942a0 0x7db9e790: 7db9e85c 601d444b 7d3942a0 00000043 Backtrace: =>1 0x60000812 (0x7db9e74c) 2 0x6019a028 (0x7db9e874) 3 0x6019157e (0x7db9e8b8) 4 0x613afc86 DSOUND_timer+0x1336() in dsound (0x7db9e9a8) 5 0x60a88bc8 in winmm (+0x28bc8) (0x7db9ea18) 6 0x603471fe call_thread_entry_point+0xe() in ntdll (0x7db9ea28) 7 0x60348832 in ntdll (+0x58832) (0x7db9eac8) 8 0x60348a2d in ntdll (+0x58a2d) (0x7db9f3b8) 9 0x6015b32f (0x7db9f4b8) 0x60000812: ret Modules: Module Address Debug info Name (124 modules) ELF 1dd000- 20c000 Deferred libgssapi_krb5.so.2 ELF 227000- 24e000 Deferred libexpat.so.1 ELF 250000- 27f000 Deferred libfontconfig.so.1 ELF 281000- 28a000 Deferred libxrender.so.1 ELF 28c000- 38d000 Deferred libx11.so.6 PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip ELF ab5000- abd000 Deferred libsm.so.6 ELF abf000- ac3000 Deferred libuuid.so.1 ELF ae9000- aec000 Deferred libcom_err.so.2 ELF af5000- afc000 Deferred libxrandr.so.2 ELF b1d000- b20000 Deferred libxcomposite.so.1 ELF b22000- b3c000 Deferred libice.so.6 ELF bf4000- bf7000 Deferred libkeyutils.so.1 ELF bfa000- c18000 Deferred ld-linux.so.2 ELF c1a000- d83000 Deferred libc.so.6 ELF d85000- d8a000 Deferred libdl.so.2 ELF d8c000- da5000 Deferred libpthread.so.0 ELF da7000- dd0000 Deferred libm.so.6 ELF dd2000- dee000 Deferred libselinux.so.1 PE ff0000- 1465000 Deferred flash10a ELF 5ca1000- 5cb6000 Deferred libresolv.so.2 ELF 5d41000- 5d66000 Deferred libk5crypto.so.3 ELF 5d99000- 5dcb000 Deferred libcrypt.so.1 ELF 5f01000- 5f0a000 Deferred libkrb5support.so.0 PE 10000000-10010000 Deferred docking ELF 6001e000-60155000 Deferred libwine.so.1 ELF 602dc000-6038b000 Export ntdll<elf> -PE 602f0000-6038b000 \ ntdll ELF 603b4000-604ff000 Deferred kernel32<elf> -PE 603d0000-604ff000 \ kernel32 ELF 604ff000-60558000 Deferred advapi32<elf> -PE 60510000-60558000 \ advapi32 ELF 60558000-60679000 Deferred ole32<elf> -PE 60570000-60679000 \ ole32 ELF 60679000-606e4000 Deferred rpcrt4<elf> -PE 60680000-606e4000 \ rpcrt4 ELF 606e4000-60704000 Deferred iphlpapi<elf> -PE 606f0000-60704000 \ iphlpapi ELF 60719000-60733000 Deferred version<elf> -PE 60720000-60733000 \ version ELF 60733000-607ff000 Deferred comctl32<elf> -PE 60740000-607ff000 \ comctl32 ELF 607ff000-60820000 Deferred imm32<elf> -PE 60810000-60820000 \ imm32 ELF 60820000-60944000 Deferred shell32<elf> -PE 60830000-60944000 \ shell32 ELF 60944000-609a3000 Deferred shlwapi<elf> -PE 60950000-609a3000 \ shlwapi ELF 609a3000-60a52000 Deferred comdlg32<elf> -PE 609b0000-60a52000 \ comdlg32 ELF 60a52000-60ae9000 Export winmm<elf> -PE 60a60000-60ae9000 \ winmm ELF 60b9f000-60c3f000 Deferred winex11<elf> -PE 60bb0000-60c3f000 \ winex11 ELF 60d79000-60d7b000 Deferred libxcb-xlib.so.0 ELF 60d7b000-60d97000 Deferred libxcb.so.1 ELF 60da0000-60da5000 Deferred libxxf86vm.so.1 ELF 60dc7000-60dfa000 Deferred uxtheme<elf> -PE 60dd0000-60dfa000 \ uxtheme ELF 60dfa000-60e34000 Deferred libcups.so.2 ELF 60f2b000-60fa9000 Deferred libgnutls.so.13 ELF 60ffb000-6100c000 Deferred libtasn1.so.3 ELF 6100c000-6107b000 Deferred libgcrypt.so.11 ELF 6107b000-6107f000 Deferred libgpg-error.so.0 ELF 6109b000-610d2000 Deferred winealsa<elf> -PE 610a0000-610d2000 \ winealsa ELF 610d2000-611b4000 Deferred libasound.so.2 ELF 611be000-611d6000 Deferred msacm32<elf> -PE 611c0000-611d6000 \ msacm32 ELF 611d6000-611ff000 Deferred msacm32<elf> -PE 611e0000-611ff000 \ msacm32 ELF 611ff000-61214000 Deferred midimap<elf> -PE 61200000-61214000 \ midimap ELF 61214000-61227000 Deferred olepro32<elf> -PE 61220000-61227000 \ olepro32 ELF 61227000-61255000 Deferred d3d8<elf> -PE 61230000-61255000 \ d3d8 ELF 61255000-61383000 Deferred wined3d<elf> -PE 61270000-61383000 \ wined3d ELF 61383000-613d1000 Export dsound<elf> -PE 61390000-613d1000 \ dsound ELF 613d1000-613e4000 Deferred security<elf> -PE 613e0000-613e4000 \ security ELF 613e4000-6140b000 Deferred netapi32<elf> -PE 613f0000-6140b000 \ netapi32 ELF 6140b000-61439000 Deferred ws2_32<elf> -PE 61410000-61439000 \ ws2_32 ELF 61439000-6148b000 Deferred wininet<elf> -PE 61440000-6148b000 \ wininet ELF 6148b000-614ae000 Deferred mpr<elf> -PE 61490000-614ae000 \ mpr ELF 614ae000-61524000 Deferred crypt32<elf> -PE 614c0000-61524000 \ crypt32 ELF 61524000-61567000 Deferred urlmon<elf> -PE 61530000-61567000 \ urlmon ELF 61567000-61585000 Deferred mscms<elf> -PE 61570000-61585000 \ mscms ELF 61585000-615bd000 Deferred liblcms.so.1 ELF 615bd000-615ff000 Deferred shdocvw<elf> -PE 615c0000-615ff000 \ shdocvw ELF 63ef9000-63f05000 Deferred libnss_files.so.2 ELF 66685000-66699000 Deferred lz32<elf> -PE 66690000-66699000 \ lz32 ELF 6c32d000-6c3d5000 Deferred gdi32<elf> -PE 6c340000-6c3d5000 \ gdi32 ELF 6c3e1000-6c53d000 Deferred user32<elf> -PE 6c400000-6c53d000 \ user32 ELF 6fbfd000-6fc34000 Deferred winspool<elf> -PE 6fc00000-6fc34000 \ winspool ELF 735b3000-736af000 Deferred oleaut32<elf> -PE 735d0000-736af000 \ oleaut32 ELF 73903000-7392c000 Deferred secur32<elf> -PE 73910000-7392c000 \ secur32 ELF 7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Program Files\QIP\qip.exe 0000001c 15 <== 0000001b 0 0000001a 0 00000019 0 00000018 0 00000009 0 0000000c 00000014 0 00000013 0 00000012 0 0000000e 0 0000000d 0 0000000f 00000015 0 00000011 0 00000010 0 00000016 00000017 0 Backtrace: =>1 0x60000812 (0x7db9e74c) 2 0x6019a028 (0x7db9e874) 3 0x6019157e (0x7db9e8b8) 4 0x613afc86 DSOUND_timer+0x1336() in dsound (0x7db9e9a8) 5 0x60a88bc8 in winmm (+0x28bc8) (0x7db9ea18) 6 0x603471fe call_thread_entry_point+0xe() in ntdll (0x7db9ea28) 7 0x60348832 in ntdll (+0x58832) (0x7db9eac8) 8 0x60348a2d in ntdll (+0x58a2d) (0x7db9f3b8) 9 0x6015b32f (0x7db9f4b8)
The Source пишет:
Bjoern Olausson пишет:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy.. All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--Tried the latest driver. --All is fine (haven't tested recording however) except pulseaudio --(doesn't work) and wine (sound is mega-glitchy, possibly because of --strange period and buffer sizes it uses: period=544, buffer=8704). --System is stable. OSS works fine.
--Also dmix causes horrible glitches everywhere. Was anyone able to make --good dmix config?
Hmmm.. Looks like it is not dmix fault. wine requested something of driver that caused all sound to be glitchy until driver is reloaded. dmesg output with debug=3 is attached. Here's some wine output: fixme:wave:ALSA_ComputeCaps Device has a minimum of 2 channels fixme:wave:ALSA_ComputeCaps Device has a minimum of 2 channels fixme:wtsapi:WTSRegisterSessionNotification Stub 0x1004e 0x00000000 fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x1ac8c8,0x1ad118): stub fixme:dsalsa:CheckXRUN Unhandled state: 0 mixer.c:305: DSOUND_BufPtrDiff: Assertion `ptr2 < buflen' failed. wine: Assertion failed at address 0x60000812 (thread 001c), starting debugger... Unhandled exception: assertion failed in 32-bit code (0x60000812). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:60000812 ESP:7db9e740 EBP:7db9e74c EFLAGS:00200206( - 00 - -IP1) EAX:00000000 EBX:00001605 ECX:0000161a EDX:00000006 ESI:602a607a EDI:602d2ff4 Stack dump: 0x7db9e740: 60198660 602d2ff4 7db9e86c 7db9e874 0x7db9e750: 6019a028 00000006 7db9e7ec 00000000 0x7db9e760: 602d2ff4 00000043 7d394298 00000068 0x7db9e770: 601db11f 7db9e7b0 7d3942a0 7d3942a0 0x7db9e780: 601ac78b 602d2ff4 00000043 7d3942a0 0x7db9e790: 7db9e85c 601d444b 7d3942a0 00000043 Backtrace: =>1 0x60000812 (0x7db9e74c) 2 0x6019a028 (0x7db9e874) 3 0x6019157e (0x7db9e8b8) 4 0x613afc86 DSOUND_timer+0x1336() in dsound (0x7db9e9a8) 5 0x60a88bc8 in winmm (+0x28bc8) (0x7db9ea18) 6 0x603471fe call_thread_entry_point+0xe() in ntdll (0x7db9ea28) 7 0x60348832 in ntdll (+0x58832) (0x7db9eac8) 8 0x60348a2d in ntdll (+0x58a2d) (0x7db9f3b8) 9 0x6015b32f (0x7db9f4b8) 0x60000812: ret Modules: Module Address Debug info Name (124 modules) ELF 1dd000- 20c000 Deferred libgssapi_krb5.so.2 ELF 227000- 24e000 Deferred libexpat.so.1 ELF 250000- 27f000 Deferred libfontconfig.so.1 ELF 281000- 28a000 Deferred libxrender.so.1 ELF 28c000- 38d000 Deferred libx11.so.6 PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip PE 400000- 723000 Deferred qip ELF ab5000- abd000 Deferred libsm.so.6 ELF abf000- ac3000 Deferred libuuid.so.1 ELF ae9000- aec000 Deferred libcom_err.so.2 ELF af5000- afc000 Deferred libxrandr.so.2 ELF b1d000- b20000 Deferred libxcomposite.so.1 ELF b22000- b3c000 Deferred libice.so.6 ELF bf4000- bf7000 Deferred libkeyutils.so.1 ELF bfa000- c18000 Deferred ld-linux.so.2 ELF c1a000- d83000 Deferred libc.so.6 ELF d85000- d8a000 Deferred libdl.so.2 ELF d8c000- da5000 Deferred libpthread.so.0 ELF da7000- dd0000 Deferred libm.so.6 ELF dd2000- dee000 Deferred libselinux.so.1 PE ff0000- 1465000 Deferred flash10a ELF 5ca1000- 5cb6000 Deferred libresolv.so.2 ELF 5d41000- 5d66000 Deferred libk5crypto.so.3 ELF 5d99000- 5dcb000 Deferred libcrypt.so.1 ELF 5f01000- 5f0a000 Deferred libkrb5support.so.0 PE 10000000-10010000 Deferred docking ELF 6001e000-60155000 Deferred libwine.so.1 ELF 602dc000-6038b000 Export ntdll<elf> -PE 602f0000-6038b000 \ ntdll ELF 603b4000-604ff000 Deferred kernel32<elf> -PE 603d0000-604ff000 \ kernel32 ELF 604ff000-60558000 Deferred advapi32<elf> -PE 60510000-60558000 \ advapi32 ELF 60558000-60679000 Deferred ole32<elf> -PE 60570000-60679000 \ ole32 ELF 60679000-606e4000 Deferred rpcrt4<elf> -PE 60680000-606e4000 \ rpcrt4 ELF 606e4000-60704000 Deferred iphlpapi<elf> -PE 606f0000-60704000 \ iphlpapi ELF 60719000-60733000 Deferred version<elf> -PE 60720000-60733000 \ version ELF 60733000-607ff000 Deferred comctl32<elf> -PE 60740000-607ff000 \ comctl32 ELF 607ff000-60820000 Deferred imm32<elf> -PE 60810000-60820000 \ imm32 ELF 60820000-60944000 Deferred shell32<elf> -PE 60830000-60944000 \ shell32 ELF 60944000-609a3000 Deferred shlwapi<elf> -PE 60950000-609a3000 \ shlwapi ELF 609a3000-60a52000 Deferred comdlg32<elf> -PE 609b0000-60a52000 \ comdlg32 ELF 60a52000-60ae9000 Export winmm<elf> -PE 60a60000-60ae9000 \ winmm ELF 60b9f000-60c3f000 Deferred winex11<elf> -PE 60bb0000-60c3f000 \ winex11 ELF 60d79000-60d7b000 Deferred libxcb-xlib.so.0 ELF 60d7b000-60d97000 Deferred libxcb.so.1 ELF 60da0000-60da5000 Deferred libxxf86vm.so.1 ELF 60dc7000-60dfa000 Deferred uxtheme<elf> -PE 60dd0000-60dfa000 \ uxtheme ELF 60dfa000-60e34000 Deferred libcups.so.2 ELF 60f2b000-60fa9000 Deferred libgnutls.so.13 ELF 60ffb000-6100c000 Deferred libtasn1.so.3 ELF 6100c000-6107b000 Deferred libgcrypt.so.11 ELF 6107b000-6107f000 Deferred libgpg-error.so.0 ELF 6109b000-610d2000 Deferred winealsa<elf> -PE 610a0000-610d2000 \ winealsa ELF 610d2000-611b4000 Deferred libasound.so.2 ELF 611be000-611d6000 Deferred msacm32<elf> -PE 611c0000-611d6000 \ msacm32 ELF 611d6000-611ff000 Deferred msacm32<elf> -PE 611e0000-611ff000 \ msacm32 ELF 611ff000-61214000 Deferred midimap<elf> -PE 61200000-61214000 \ midimap ELF 61214000-61227000 Deferred olepro32<elf> -PE 61220000-61227000 \ olepro32 ELF 61227000-61255000 Deferred d3d8<elf> -PE 61230000-61255000 \ d3d8 ELF 61255000-61383000 Deferred wined3d<elf> -PE 61270000-61383000 \ wined3d ELF 61383000-613d1000 Export dsound<elf> -PE 61390000-613d1000 \ dsound ELF 613d1000-613e4000 Deferred security<elf> -PE 613e0000-613e4000 \ security ELF 613e4000-6140b000 Deferred netapi32<elf> -PE 613f0000-6140b000 \ netapi32 ELF 6140b000-61439000 Deferred ws2_32<elf> -PE 61410000-61439000 \ ws2_32 ELF 61439000-6148b000 Deferred wininet<elf> -PE 61440000-6148b000 \ wininet ELF 6148b000-614ae000 Deferred mpr<elf> -PE 61490000-614ae000 \ mpr ELF 614ae000-61524000 Deferred crypt32<elf> -PE 614c0000-61524000 \ crypt32 ELF 61524000-61567000 Deferred urlmon<elf> -PE 61530000-61567000 \ urlmon ELF 61567000-61585000 Deferred mscms<elf> -PE 61570000-61585000 \ mscms ELF 61585000-615bd000 Deferred liblcms.so.1 ELF 615bd000-615ff000 Deferred shdocvw<elf> -PE 615c0000-615ff000 \ shdocvw ELF 63ef9000-63f05000 Deferred libnss_files.so.2 ELF 66685000-66699000 Deferred lz32<elf> -PE 66690000-66699000 \ lz32 ELF 6c32d000-6c3d5000 Deferred gdi32<elf> -PE 6c340000-6c3d5000 \ gdi32 ELF 6c3e1000-6c53d000 Deferred user32<elf> -PE 6c400000-6c53d000 \ user32 ELF 6fbfd000-6fc34000 Deferred winspool<elf> -PE 6fc00000-6fc34000 \ winspool ELF 735b3000-736af000 Deferred oleaut32<elf> -PE 735d0000-736af000 \ oleaut32 ELF 73903000-7392c000 Deferred secur32<elf> -PE 73910000-7392c000 \ secur32 ELF 7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Program Files\QIP\qip.exe 0000001c 15 <== 0000001b 0 0000001a 0 00000019 0 00000018 0 00000009 0 0000000c 00000014 0 00000013 0 00000012 0 0000000e 0 0000000d 0 0000000f 00000015 0 00000011 0 00000010 0 00000016 00000017 0 Backtrace: =>1 0x60000812 (0x7db9e74c) 2 0x6019a028 (0x7db9e874) 3 0x6019157e (0x7db9e8b8) 4 0x613afc86 DSOUND_timer+0x1336() in dsound (0x7db9e9a8) 5 0x60a88bc8 in winmm (+0x28bc8) (0x7db9ea18) 6 0x603471fe call_thread_entry_point+0xe() in ntdll (0x7db9ea28) 7 0x60348832 in ntdll (+0x58832) (0x7db9eac8) 8 0x60348a2d in ntdll (+0x58a2d) (0x7db9f3b8) 9 0x6015b32f (0x7db9f4b8)
Ok, got pulseaudio to work, but it causes the same problem - sound becomes mega glitchy everywhere. So looks like even if driver doesn't crash the system, playback is still unstable and can become glitchy. Also I can not make Fedora 9 to load snd-sbxfi automatically. It ignores modprobe.conf and pulseudio does not detect snd-sbxfi as driver for my card.
At Sat, 25 Oct 2008 21:40:40 +0100, Jason Harvey wrote:
Takashi Iwai wrote:
At Sat, 25 Oct 2008 21:42:55 +0200, Thomas Scheunemann wrote:
My solution is to use roundup_pow_of_two() instead of the own funciton. This should work better in general.
I certainly agree that it is better to use an already defined function instead of reinventing the wheel.
Anyway, I updated the repo (and rebased, sorry), updated the snapshot, too.
But this new version causes an immediate reboot on my machine even with the previously working speaker-test. If I interpret linux/log2.h correctly the desired function should be order_base_2 instead of roundup_pow_of_two. At least it works for me after that exchange.
Oh my. You're right, it must be order_base_2(), of course. I was too hurry to fix a bug after the server crash :)
Now fixed and updated. Thanks!
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix. aplay still works but only with dmix.
Do you have no sound quality problem with dmix like other people?
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
What about base_rate=48000 option?
Machine did not crash at any point!
Heh, finally.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
You can ignore what stated in SUPPORTED_KERNELS. It's just an excuse not to support vendor kernels. Distro vendor kernels are often way too modified to support properly by the out-of-tree driver.
FWIW, the current alsa-driver (and unstable) snapshot should work fine with up to 2.6.28-rc1 kernel. sbxfi is marked to be available on 2.6.25 or later kernels. It won't be built for earlier kernels.
thanks,
Takashi
At Sat, 25 Oct 2008 23:57:53 +0200, Bjoern Olausson wrote:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Hm. The probme like stuttering is a bit hard to analyze. In most cases, it comes from the inaccurate PCM hwptr (i.e. the value calculated in PCM pointer callback is wrong), but not always like that.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy..
To be sure - this symptom is only on sbxfi, right?
All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Yes, please...
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
I'm not sure whether this is really related with sbxfi. For checking that, you can load snd-dummy driver instead, and run smplayer with it.
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
A few important features are in my mind: - continuous rate support - multi-channel playback - multi-stream playback
Not sure whether I can achieve any of them without a document, though.
thanks,
Takashi
At Sun, 26 Oct 2008 09:32:08 +0300, The Source wrote:
Bjoern Olausson пишет:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy.. All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Tried the latest driver. All is fine (haven't tested recording however) except pulseaudio (doesn't work) and wine (sound is mega-glitchy, possibly because of strange period and buffer sizes it uses: period=544, buffer=8704).
Maybe due to the sample rate? I guess with 48kHz it would be a more sane period/buffer size.
thanks,
Takashi
Takashi Iwai wrote:
At Sat, 25 Oct 2008 21:40:40 +0100, Jason Harvey wrote:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix. aplay still works but only with dmix.
Do you have no sound quality problem with dmix like other people?
No dmix trouble when I run "aplay -Dplug:dmix:0 wn.wav" produces perfect sound. Wav is three minutes long and it was 100% ok throughout.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
What about base_rate=48000 option?
Genius! It is now working through pulse PERFECTLY. Have two instances of mplayer playing right this second. Can hear both tracks playing without any trouble.
I just edited one line in /etc/pulse/daemon.conf not sure it is the option you were talking about above but it works for me!
Will put the card into my 64bit main machine in a minute and try it there :)
Jason
Takashi Iwai пишет:
At Sun, 26 Oct 2008 09:32:08 +0300, The Source wrote:
Bjoern Olausson пишет:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy.. All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Tried the latest driver. All is fine (haven't tested recording however) except pulseaudio (doesn't work) and wine (sound is mega-glitchy, possibly because of strange period and buffer sizes it uses: period=544, buffer=8704).
Maybe due to the sample rate? I guess with 48kHz it would be a more sane period/buffer size.
thanks,
Takashi
With that option pulseaudio works better (still some glitches, but very small). But wine still corrupts sound.
Takashi Iwai пишет:
At Sun, 26 Oct 2008 09:32:08 +0300, The Source wrote:
Bjoern Olausson пишет:
Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.
Confirmed. The stuttering got better, but is still present.
Xine works flawless.
aplay still works but only with dmix.
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a bit scratchy.. All other common samplingrates work flawless. Could someone confirm that? http://tmp.olausson.de/30days/0_16_s_8000.wav http://tmp.olausson.de/30days/0_16_s_11025.wav http://tmp.olausson.de/30days/0_16_s_96000.wav
Just using "aplay file.wav"
More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz "mplayer file.wav"
mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
Now also almost working in gnome with pulse, sound is recognisable but with lots of interference/corruption.
No pulseaudio on my machine. Sry.
Machine did not crash at any point!
Just observed a X crash when using smplayer to play a avi. When I closed smplayer while the movie was playing X crashed. (But could be unrelated to audio, I could not reproduce it)
But no crash or freez so far.
This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 2.6.25 or earlier?
I am using vanilla 2.6.27.3
Thanks for you awesome work!
By the way, what's next on your plan when stereo output and recording is working flawless?
kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Tried the latest driver. All is fine (haven't tested recording however) except pulseaudio (doesn't work) and wine (sound is mega-glitchy, possibly because of strange period and buffer sizes it uses: period=544, buffer=8704).
Maybe due to the sample rate? I guess with 48kHz it would be a more sane period/buffer size.
thanks,
Takashi
--With that option pulseaudio works better (still some glitches, but --very --small). But wine still corrupts sound.
Hmmm....after sound got currupted, I started playing a file with xmms. Sound was horrible, but I couldn't get hw_params, because the contents of that file are 'closed'! How can this be if xmms uses alsa at that time??
Excuse me. I am a new one and just wonder if I can see the email I post. :)> Date: Sun, 26 Oct 2008 12:17:43 +0300> From: thesourcehim@gmail.com> To: tiwai@suse.de> CC: alsa-devel@alsa-project.org> Subject: Re: [alsa-devel] Backported sbxfi driver, possible fix> > Takashi Iwai пишет:> > At Sun, 26 Oct 2008 09:32:08 +0300,> > The Source wrote:> > > >> Bjoern Olausson пишет:> >> > >>>> Latest unstable (25Oct 19:57) works from command line with mplayer,> >>>> without the proc oss fix.> >>>>> >>>> > >>>> > >>> Confirmed.> >>> The stuttering got better, but is still present.> >>>> >>> Xine works flawless.> >>>> >>> > >>> > >>>> aplay still works but only with dmix.> >>>>> >>>> > >>>> > >>> Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a> >>> bit scratchy..> >>> All other common samplingrates work flawless. Could someone confirm that?> >>> http://tmp.olausson.de/30days/0_16_s_8000.wav%3E >>> http://tmp.olausson.de/30days/0_16_s_11025.wav%3E >>> http://tmp.olausson.de/30days/0_16_s_96000.wav%3E >>>> >>> Just using "aplay file.wav"> >>>> >>> More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz> >>> "mplayer file.wav"> >>>> >>> mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.> >>>> >>> > >>> > >>>> Now also almost working in gnome with pulse, sound is recognisable but> >>>> with lots of interference/corruption.> >>>>> >>>> > >>>> > >>> No pulseaudio on my machine. Sry.> >>>> >>> > >>> > >>>> Machine did not crash at any point!> >>>>> >>>> > >>>> > >>> Just observed a X crash when using smplayer to play a avi. When I> >>> closed smplayer while the movie was playing X crashed. (But could be> >>> unrelated to audio, I could not reproduce it)> >>>> >>> But no crash or freez so far.> >>>> >>> > >>> > >>>> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says> >>>> 2.6.25 or earlier?> >>>>> >>>> > >>>> > >>> I am using vanilla 2.6.27.3> >>>> >>> Thanks for you awesome work!> >>>> >>> By the way, what's next on your plan when stereo output and recording> >>> is working flawless?> >>>> >>>> >>> kind regards> >>> Bjoern> >>> _______________________________________________> >>> Alsa-devel mailing list> >>> Alsa-devel@alsa-project.org> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel%3E >>>> >>> > >>> > >> Tried the latest driver.> >> All is fine (haven't tested recording however) except pulseaudio > >> (doesn't work) and wine (sound is mega-glitchy, possibly because of > >> strange period and buffer sizes it uses: period=544, buffer=8704). > >> > >> > Maybe due to the sample rate? I guess with 48kHz it would be a more> > sane period/buffer size.> >> >> > thanks,> >> > Takashi> >> > > --With that option pulseaudio works better (still some glitches, but --very> --small). But wine still corrupts sound.> > Hmmm....after sound got currupted, I started playing a file with xmms. > Sound was horrible, but I couldn't get hw_params, because the contents > of that file are 'closed'! How can this be if xmms uses alsa at that time??> _______________________________________________> Alsa-devel mailing list> Alsa-devel@alsa-project.org> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel _________________________________________________________________ 谈话枯燥无味？让MSN魔法书来点缀您的MSN！ http://im.live.cn/emoticons/?ID=6
Takashi Iwai wrote:
A few important features are in my mind:
- continuous rate support
In the sources, you have:
Note: 44.1kHz is possible, but is more complex because it uses a method whereby the channel ring marks each sample in the channel ring as valid or not, so to get 44.1kHz, some samples are simply tagged invalid. The "channel ring" is not the ring buffer that is used to get sound samples to the card. The "channel ring" is used to pass samples between different processing modules on the card. One of these processing modules is the SRC, another is the INs/OUTs, another is the hardware mixer, and yet another is the DSP.
Do I understand correctly that the card internally resamples the sound to a different rate using the zero-order-hold method? If so, I'd rather not see this feature at all unless the "i_want_horrible_sound" parameter is passed, because software can do it better, and some program will surely default to using this hardware misfeature.
OTOH, Wine is doing this for ages and nobody except me complains (http://bugs.winehq.org/show_bug.cgi?id=14717)
Alexander E. Patrakov пишет:
Takashi Iwai wrote:
A few important features are in my mind:
- continuous rate support
In the sources, you have:
Note: 44.1kHz is possible, but is more complex because it uses a method whereby the channel ring marks each sample in the channel ring as valid or not, so to get 44.1kHz, some samples are simply tagged invalid. The "channel ring" is not the ring buffer that is used to get sound samples to the card. The "channel ring" is used to pass samples between different processing modules on the card. One of these processing modules is the SRC, another is the INs/OUTs, another is the hardware mixer, and yet another is the DSP.
Do I understand correctly that the card internally resamples the sound to a different rate using the zero-order-hold method? If so, I'd rather not see this feature at all unless the "i_want_horrible_sound" parameter is passed, because software can do it better, and some program will surely default to using this hardware misfeature.
OTOH, Wine is doing this for ages and nobody except me complains (http://bugs.winehq.org/show_bug.cgi?id=14717)
Wine causes sound corruption with this driver for me (along with some other software like Pulseaudio).
At Mon, 27 Oct 2008 08:32:05 +0300, The Source wrote:
Alexander E. Patrakov пишет:
Takashi Iwai wrote:
A few important features are in my mind:
- continuous rate support
In the sources, you have:
Note: 44.1kHz is possible, but is more complex because it uses a method whereby the channel ring marks each sample in the channel ring as valid or not, so to get 44.1kHz, some samples are simply tagged invalid. The "channel ring" is not the ring buffer that is used to get sound samples to the card. The "channel ring" is used to pass samples between different processing modules on the card. One of these processing modules is the SRC, another is the INs/OUTs, another is the hardware mixer, and yet another is the DSP.
Do I understand correctly that the card internally resamples the sound to a different rate using the zero-order-hold method? If so, I'd rather not see this feature at all unless the "i_want_horrible_sound" parameter is passed, because software can do it better, and some program will surely default to using this hardware misfeature.
OTOH, Wine is doing this for ages and nobody except me complains (http://bugs.winehq.org/show_bug.cgi?id=14717)
Wine causes sound corruption with this driver for me (along with some other software like Pulseaudio).
Does it happen also with base_rate=48000 option?
It'd be helpful if someone can summarize the working and non-working cases. For example,
global info: 1. sbxfi driver version (date & HEADs) 2. base_rate value 3. system details (x86-64, distro, kernel version, etc)
for each app: A. Application name / version B. working or not-working, problem descriptions C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params) D. period_size and buffer_size (ditto, or in kernel message) E. any special options
Maybe also nice on Wiki...
thanks,
Takashi
Takashi Iwai пишет:
At Mon, 27 Oct 2008 08:32:05 +0300, The Source wrote:
Alexander E. Patrakov пишет:
Takashi Iwai wrote:
A few important features are in my mind:
- continuous rate support
In the sources, you have:
Note: 44.1kHz is possible, but is more complex because it uses a method whereby the channel ring marks each sample in the channel ring as valid or not, so to get 44.1kHz, some samples are simply tagged invalid. The "channel ring" is not the ring buffer that is used to get sound samples to the card. The "channel ring" is used to pass samples between different processing modules on the card. One of these processing modules is the SRC, another is the INs/OUTs, another is the hardware mixer, and yet another is the DSP.
Do I understand correctly that the card internally resamples the sound to a different rate using the zero-order-hold method? If so, I'd rather not see this feature at all unless the "i_want_horrible_sound" parameter is passed, because software can do it better, and some program will surely default to using this hardware misfeature.
OTOH, Wine is doing this for ages and nobody except me complains (http://bugs.winehq.org/show_bug.cgi?id=14717)
Wine causes sound corruption with this driver for me (along with some other software like Pulseaudio).
Does it happen also with base_rate=48000 option?
Yes.
It'd be helpful if someone can summarize the working and non-working cases. For example,
global info:
- sbxfi driver version (date & HEADs)
- base_rate value
- system details (x86-64, distro, kernel version, etc)
26.10.2008 snapshot, don't remember the time. 96000 and 48000 x86-64 Fedora 9 kernel-2.6.26.6-79.fc9.x86_64
for each app: A. Application name / version B. working or not-working, problem descriptions C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params) D. period_size and buffer_size (ditto, or in kernel message) E. any special options
Wine 1.1.6 Sound glitches Both ALSA and OSS Very weird values, I reported before.
Maybe also nice on Wiki...
thanks,
Takashi
At Mon, 27 Oct 2008 10:15:07 +0500, Alexander E. Patrakov wrote:
Takashi Iwai wrote:
A few important features are in my mind:
- continuous rate support
In the sources, you have:
Note: 44.1kHz is possible, but is more complex because it uses a method whereby the channel ring marks each sample in the channel ring as valid or not, so to get 44.1kHz, some samples are simply tagged invalid. The "channel ring" is not the ring buffer that is used to get sound samples to the card. The "channel ring" is used to pass samples between different processing modules on the card. One of these processing modules is the SRC, another is the INs/OUTs, another is the hardware mixer, and yet another is the DSP.
Do I understand correctly that the card internally resamples the sound to a different rate using the zero-order-hold method? If so, I'd rather not see this feature at all unless the "i_want_horrible_sound" parameter is passed, because software can do it better, and some program will surely default to using this hardware misfeature.
Likely it's a wrong guess. emu20k1 has the following register bits.
# define SRCCTL_PITCH_ROM (3<<11) /* pitch ROM select */ # define SRCCTL_PITCH_HIGH (0<<11) /* 0 to 8.0: very high quality */ # define SRCCTL_PITCH_EXT_HIGH (1<<11) /* 0.26 to 1.72: extermely high qual.*/ # define SRCCTL_PITCH_88kHZ (2<<11) /* 1.8375: 88.2kHz 48kHz */ # define SRCCTL_PITCH_96KHZ (3<<11) /* 2.0: 96kHz 48kHz */
Takashi
At Mon, 27 Oct 2008 09:34:27 +0300, The Source wrote:
Takashi Iwai пишет:
At Mon, 27 Oct 2008 08:32:05 +0300, The Source wrote:
Alexander E. Patrakov пишет:
Takashi Iwai wrote:
A few important features are in my mind:
- continuous rate support
In the sources, you have:
Note: 44.1kHz is possible, but is more complex because it uses a method whereby the channel ring marks each sample in the channel ring as valid or not, so to get 44.1kHz, some samples are simply tagged invalid. The "channel ring" is not the ring buffer that is used to get sound samples to the card. The "channel ring" is used to pass samples between different processing modules on the card. One of these processing modules is the SRC, another is the INs/OUTs, another is the hardware mixer, and yet another is the DSP.
Do I understand correctly that the card internally resamples the sound to a different rate using the zero-order-hold method? If so, I'd rather not see this feature at all unless the "i_want_horrible_sound" parameter is passed, because software can do it better, and some program will surely default to using this hardware misfeature.
OTOH, Wine is doing this for ages and nobody except me complains (http://bugs.winehq.org/show_bug.cgi?id=14717)
Wine causes sound corruption with this driver for me (along with some other software like Pulseaudio).
Does it happen also with base_rate=48000 option?
Yes.
It'd be helpful if someone can summarize the working and non-working cases. For example,
global info:
- sbxfi driver version (date & HEADs)
- base_rate value
- system details (x86-64, distro, kernel version, etc)
26.10.2008 snapshot, don't remember the time.
Add prefix numbers (1, 2, 3) to each item.
See HEAD files in alsa-driver*/ and alsa-driver*/alsa-kernel, and take the first line.
96000 and 48000 x86-64 Fedora 9 kernel-2.6.26.6-79.fc9.x86_64
for each app: A. Application name / version B. working or not-working, problem descriptions C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params) D. period_size and buffer_size (ditto, or in kernel message) E. any special options
Wine 1.1.6
Add prefix to each item, too.
Sound glitches Both ALSA and OSS Very weird values, I reported before.
Write it up again.
Takashi
Alexander E. Patrakov wrote:
Takashi Iwai wrote:
Note: 44.1kHz is possible, but is more complex because it uses a method whereby the channel ring marks each sample in the channel ring as valid or not, so to get 44.1kHz, some samples are simply tagged invalid. The "channel ring" is not the ring buffer that is used to get sound samples to the card. The "channel ring" is used to pass samples between different processing modules on the card. One of these processing modules is the SRC, another is the INs/OUTs, another is the hardware mixer, and yet another is the DSP.
Do I understand correctly that the card internally resamples the sound to a different rate using the zero-order-hold method? If so, I'd rather not see this feature at all unless the "i_want_horrible_sound" parameter is passed, because software can do it better, and some program will surely default to using this hardware misfeature.
Alex,
I added that comment (takashi cut and pasted my text). No resampling is done. Say you have a buffer that is running at 48kHz. So you have say 480 samples at the 48kHz rate. But if you want to transfer 44.1kHz rate samples over it, you only want 441 samples to be there, so what to do with the left over 39 samples. What the xfi does is next to each sample it adds a "valid" tag. So, the xfi adds those 39 samples but marks them as "invalid". The xfi then drops the 39 "invalid" samples, leaving only the 441 "valid" samples just before sending them at 44.1kHz to the DAC. Does this explain things a bit better. FYI, the xfi actually works internally at 384kHz, so it is actually marking a lot of samples as "invalid".
Kind Regards
James
On Mon, Oct 27, 2008 at 07:28, Takashi Iwai tiwai@suse.de wrote:
It'd be helpful if someone can summarize the working and non-working cases. For example,
global info:
- sbxfi driver version (date & HEADs)
- base_rate value
- system details (x86-64, distro, kernel version, etc)
for each app: A. Application name / version B. working or not-working, problem descriptions C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params) D. period_size and buffer_size (ditto, or in kernel message) E. any special options
Maybe also nice on Wiki...
thanks,
Takashi
1. sbxfi driver version (date & HEADs) 10/27/2008 05:55:00 PM
./HEAD 7d1c628613fa81595d145c897530e2eb0fbbf922 Merge commit 'stable/master' 390dde1aeba0aec19bd121dfcb2147a1bc721756 jack - fix build with older kernels 2e5fb80ee0cfed9c9ec4b977822b13d7a8d4790f Merge commit 'stable/master' d338c02cda2d5525e7ad3b35a2d51438c8fc8f08 x86 mach: test for mach_apic.h to skip empty directories 75b71fe1b618af2250692144205e71dede39aeb0 Merge commit 'stable/master' 795b6cd7e0006e2c62a9c7004555b5b22c9e4329 alsa-info - Fix quoting 8682b8b4ced855b01639d85098ca7de23db87c3d Merge branch 'topic/snd-hrtimer' 46195d51d453ee7f1579028ba0407efafe03b3d4 snd-hrtimer - Add kernel version dependency 2.6.24 or later 058cbcd459dcfa90b40587932d4a2069497fa849 Merge branch 'topic/snd-hrtimer' 8cadf99a5ca45aef2c4e7970e71bf1571163018d Merge branch 'topic/tools'
./alsa-kernel/HEAD 16fb0167b6a59608defbc164dad266613fae1fc5 Merge commit 'stable/master' 58e5beb32b45cf7a09733886f600fe6442586cad Merge branch 'topic/fix/hda' e044c39ae258678d6ebb09fccb2a0fdf7ec51847 ALSA: hda - Restore default pin configs for realtek codecs ec99a09ebe531c8d211b51d9e33d3a7341080e17 Merge branch 'topic/fix/misc' 2f1e593d4209d0194f9639c5d11aa91171435963 sound: use a common working email address 07580a206c3755724fea57bc84a4a4064ee62c00 Merge commit 'stable/master' b69dffcb0a963ff7f0d9bad391c2c9bae37a837e Merge branch 'topic/hda-next' 74aeaabc3e452b29bc1b9eac5aa48923569f8a4e ALSA: hda: add support for jack detection on IDT codecs. 50a9f7905fb3e6ae25e80ba443a14d878caef0c9 ALSA: hda: add snd_hda_get_jack* functions 282cd76ffca781013151344c4b0f9229e9ea3c35 ALSA: hda: dynamic jack id
2. base_rate value rate: 96000 (96000/1)
3. system details
Gentoo Linux Portage 2.1.4.5 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.27.3-unpatched x86_64) ================================================================= System uname: 2.6.27.3-unpatched x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Timestamp of tree: Sun, 26 Oct 2008 16:18:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
A) MPlayer dev-SVN-r27725-4.1.2 B) Working, but horrible, crackeling sound at samplingrate 11025Hz 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200 (3200, 48000 and 96000 are fine) checked with WindowsXP. In XP the sound is nice and clear. So the files are good. C) OSS (see bug-mplayer file) D) See bug-mplayer file E) nothing
A) Xine 0.99.5 B) No samplingrate is clear, all is crackeling.... C) ALSA I guess (bug-mplayer file) D) See bug-xine file E) nothing
So one wired thing: I first tested mplayer... all samplingrates except 3200, 48000 and 96000 were bad. Then I tested xine... everything was bad. Then I tested mplayer again to dump the info into the files (bug-mplayer) suddenly all samplerates were fine.... testing again and all went bad again? But basically you can say everything is crapy right now.
Kind regards Bjoern
James Courtier-Dutton wrote:
Alex,
I added that comment (takashi cut and pasted my text). No resampling is done. Say you have a buffer that is running at 48kHz. So you have say 480 samples at the 48kHz rate. But if you want to transfer 44.1kHz rate samples over it, you only want 441 samples to be there, so what to do with the left over 39 samples. What the xfi does is next to each sample it adds a "valid" tag. So, the xfi adds those 39 samples but marks them as "invalid". The xfi then drops the 39 "invalid" samples, leaving only the 441 "valid" samples just before sending them at 44.1kHz to the DAC. Does this explain things a bit better?
Yes, thanks!
At Mon, 27 Oct 2008 07:28:51 +0100, I wrote:
It'd be helpful if someone can summarize the working and non-working cases. For example,
global info:
Forgot an important thing:
0. SBXFI model (product name, PCI ID, PCI SSID, cat /proc/asound/cards entry)
Takashi
- sbxfi driver version (date & HEADs)
- base_rate value
- system details (x86-64, distro, kernel version, etc)
for each app: A. Application name / version B. working or not-working, problem descriptions C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params) D. period_size and buffer_size (ditto, or in kernel message) E. any special options
Maybe also nice on Wiki...
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Tue, 28 Oct 2008 01:10:43 +0100, Bjoern Olausson wrote:
On Mon, Oct 27, 2008 at 07:28, Takashi Iwai tiwai@suse.de wrote:
It'd be helpful if someone can summarize the working and non-working cases. For example,
global info:
- sbxfi driver version (date & HEADs)
- base_rate value
- system details (x86-64, distro, kernel version, etc)
for each app: A. Application name / version B. working or not-working, problem descriptions C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params) D. period_size and buffer_size (ditto, or in kernel message) E. any special options
Maybe also nice on Wiki...
thanks,
Takashi
Forgot to ask: which SBXFI model? The product name, PCI ID, PCI SSID, and /proc/asound/cards entry please.
- base_rate value rate: 96000 (96000/1)
What about base_rate=48000?
BTW, I changed now base_rate to 48000 for testing as I got more positive results with it.
A) MPlayer dev-SVN-r27725-4.1.2 B) Working, but horrible, crackeling sound at samplingrate 11025Hz 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200 (3200, 48000 and 96000 are fine) checked with WindowsXP. In XP the sound is nice and clear. So the files are good. C) OSS (see bug-mplayer file) D) See bug-mplayer file E) nothing
What if you do the following (as root)?
# echo "mplayer 0 0 direct" > /proc/asound/card0/pcm0p/oss This will disable the conversion in OSS emulation, so mplayer will take 96kHz as is.
A) Xine 0.99.5 B) No samplingrate is clear, all is crackeling.... C) ALSA I guess (bug-mplayer file) D) See bug-xine file E) nothing
Not sure about this...
Takashi
At Mon, 27 Oct 2008 20:08:04 +0000, James Courtier-Dutton wrote:
Alexander E. Patrakov wrote:
Takashi Iwai wrote:
Note: 44.1kHz is possible, but is more complex because it uses a method whereby the channel ring marks each sample in the channel ring as valid or not, so to get 44.1kHz, some samples are simply tagged invalid. The "channel ring" is not the ring buffer that is used to get sound samples to the card. The "channel ring" is used to pass samples between different processing modules on the card. One of these processing modules is the SRC, another is the INs/OUTs, another is the hardware mixer, and yet another is the DSP.
Do I understand correctly that the card internally resamples the sound to a different rate using the zero-order-hold method? If so, I'd rather not see this feature at all unless the "i_want_horrible_sound" parameter is passed, because software can do it better, and some program will surely default to using this hardware misfeature.
Alex,
I added that comment (takashi cut and pasted my text). No resampling is done. Say you have a buffer that is running at 48kHz. So you have say 480 samples at the 48kHz rate. But if you want to transfer 44.1kHz rate samples over it, you only want 441 samples to be there, so what to do with the left over 39 samples. What the xfi does is next to each sample it adds a "valid" tag. So, the xfi adds those 39 samples but marks them as "invalid". The xfi then drops the 39 "invalid" samples, leaving only the 441 "valid" samples just before sending them at 44.1kHz to the DAC. Does this explain things a bit better. FYI, the xfi actually works internally at 384kHz, so it is actually marking a lot of samples as "invalid".
Hm, so what is special about using 44.1kHz if many samples in the audio-ring are already marked as invalid even with 48kHz?
It'd be helpful if you could provide a bit more information (or a pseudo-code) for supporting non-48/96kHz samples.
thanks,
Takashi
But that surely isn't bitperfect, right?
2008/10/27 James Courtier-Dutton James@superbug.co.uk
Alex,
I added that comment (takashi cut and pasted my text). No resampling is done. Say you have a buffer that is running at 48kHz. So you have say 480 samples at the 48kHz rate. But if you want to transfer 44.1kHz rate samples over it, you only want 441 samples to be there, so what to do with the left over 39 samples. What the xfi does is next to each sample it adds a "valid" tag. So, the xfi adds those 39 samples but marks them as "invalid". The xfi then drops the 39 "invalid" samples, leaving only the 441 "valid" samples just before sending them at 44.1kHz to the DAC. Does this explain things a bit better. FYI, the xfi actually works internally at 384kHz, so it is actually marking a lot of samples as "invalid".
Kind Regards
James _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Tue, Oct 28, 2008 at 08:14, Takashi Iwai tiwai@suse.de wrote:
Forgot to ask: which SBXFI model? The product name, PCI ID, PCI SSID, and /proc/asound/cards entry please.
01:00.0 0401: 1102:0005 Subsystem: 1102:0021 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
01:00.0 Multimedia audio controller: Creative Labs SB X-Fi Subsystem: Creative Labs X-Fi Platinum Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
- base_rate value rate: 96000 (96000/1)
What about base_rate=48000?
BTW, I changed now base_rate to 48000 for testing as I got more positive results with it.
Should I pass this parameter during ./configure or as module parameter?
A) MPlayer dev-SVN-r27725-4.1.2 B) Working, but horrible, crackeling sound at samplingrate 11025Hz 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200 (3200, 48000 and 96000 are fine) checked with WindowsXP. In XP the sound is nice and clear. So the files are good. C) OSS (see bug-mplayer file) D) See bug-mplayer file E) nothing
What if you do the following (as root)?
# echo "mplayer 0 0 direct" > /proc/asound/card0/pcm0p/oss
Tested... but gives only white noise, no matter what samplingrate or file....
This will disable the conversion in OSS emulation, so mplayer will take 96kHz as is.
A) Xine 0.99.5 B) No samplingrate is clear, all is crackeling.... C) ALSA I guess (bug-mplayer file) D) See bug-xine file E) nothing
Not sure about this...
Takashi
Bjoern
At Tue, 28 Oct 2008 14:48:01 +0100, Bjoern Olausson wrote:
On Tue, Oct 28, 2008 at 08:14, Takashi Iwai tiwai@suse.de wrote:
Forgot to ask: which SBXFI model? The product name, PCI ID, PCI SSID, and /proc/asound/cards entry please.
01:00.0 0401: 1102:0005 Subsystem: 1102:0021 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mAPME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
01:00.0 Multimedia audio controller: Creative Labs SB X-Fi Subsystem: Creative Labs X-Fi Platinum Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mAPME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
- base_rate value rate: 96000 (96000/1)
What about base_rate=48000?
BTW, I changed now base_rate to 48000 for testing as I got more positive results with it.
Should I pass this parameter during ./configure or as module parameter?
As a module parameter, either in somewhere modprobe.conf or such, or via modprobe command line option.
I changed the latest version to use 48k as default, so you can just grab the latest snapshot, too.
A) MPlayer dev-SVN-r27725-4.1.2 B) Working, but horrible, crackeling sound at samplingrate 11025Hz 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200 (3200, 48000 and 96000 are fine) checked with WindowsXP. In XP the sound is nice and clear. So the files are good. C) OSS (see bug-mplayer file) D) See bug-mplayer file E) nothing
What if you do the following (as root)?
# echo "mplayer 0 0 direct" > /proc/asound/card0/pcm0p/ossTested... but gives only white noise, no matter what samplingrate or file....
Weird. What happens if you force to the sample rate to 48000 via mplayer's option?
Takashi
James Courtier-Dutton wrote:
Alexander E. Patrakov wrote: Alex,
I added that comment (takashi cut and pasted my text). No resampling is done. Say you have a buffer that is running at 48kHz. So you have say 480 samples at the 48kHz rate. But if you want to transfer 44.1kHz rate samples over it, you only want 441 samples to be there, so what to do with the left over 39 samples. What the xfi does is next to each sample it adds a "valid" tag. So, the xfi adds those 39 samples but marks them as "invalid". The xfi then drops the 39 "invalid" samples, leaving only the 441 "valid" samples just before sending them at 44.1kHz to the DAC. Does this explain things a bit better. FYI, the xfi actually works internally at 384kHz, so it is actually marking a lot of samples as "invalid".
Kind Regards
James
James,
Thanks a lot for the info. Does it mean that the core runs at 384kHz, while codes are clocked by another clock signal PLL'd from the master clock to the required frequency? Theoretically this could allow running different outputs/channels at diferrent sample rates :)
Pavel.
On Tue, Oct 28, 2008 at 15:12, Takashi Iwai tiwai@suse.de wrote:
At Tue, 28 Oct 2008 14:48:01 +0100, Bjoern Olausson wrote:
On Tue, Oct 28, 2008 at 08:14, Takashi Iwai tiwai@suse.de wrote:
Forgot to ask: which SBXFI model? The product name, PCI ID, PCI SSID, and /proc/asound/cards entry please.
01:00.0 0401: 1102:0005 Subsystem: 1102:0021 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mAPME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
01:00.0 Multimedia audio controller: Creative Labs SB X-Fi Subsystem: Creative Labs X-Fi Platinum Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mAPME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
- base_rate value rate: 96000 (96000/1)
What about base_rate=48000?
BTW, I changed now base_rate to 48000 for testing as I got more positive results with it.
Should I pass this parameter during ./configure or as module parameter?
As a module parameter, either in somewhere modprobe.conf or such, or via modprobe command line option.
I changed the latest version to use 48k as default, so you can just grab the latest snapshot, too.
A) MPlayer dev-SVN-r27725-4.1.2 B) Working, but horrible, crackeling sound at samplingrate 11025Hz 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200 (3200, 48000 and 96000 are fine) checked with WindowsXP. In XP the sound is nice and clear. So the files are good. C) OSS (see bug-mplayer file) D) See bug-mplayer file E) nothing
What if you do the following (as root)?
# echo "mplayer 0 0 direct" > /proc/asound/card0/pcm0p/ossTested... but gives only white noise, no matter what samplingrate or file....
Weird. What happens if you force to the sample rate to 48000 via mplayer's option?
Takashi
Sry for the delayed testing, but my "Diplomarbeit" has to be finish on Monday... so I am a bit in a hurry...
But anyway:
Tested 10/30/2008 07:05:00 AM 712e4debd7b0c84ee68342cdc56ae8bdb0119b75 Merge commit 'stable/master' 0f6ba093f8aa7a9e2caff2a697edcfeaddd4e0a1 Remove __attribute__ form dev_set_name() wrapper 1aec09cd650c40b93eb1956ff8396e61a52ccef3 Merge commit 'stable/master' 277a3f5f74b6ff1f7cb719f7bfbb2ccdde252cf2 Add dev_name() and dev_set_name() wrappers e3d42c6eae1ea6d43af6223d9338adf75e63f841 Merge branch 'topic/tools' ff936f865a57e68289d6bd4b8da74670bf04a378 Remove topic/snd-hrtimer branch 1bf544cf592b7c2270ba1c28e67067d9c244e0e9 Merge commit 'stable/master' d9aebb8d6130d1fc33a9ac4be62550914b2b0559 Merge branch 'topic/snd-hrtimer' 4f169e7e1cfa7a85e15920cda84eb7a8e80acf81 Add snd-hrtimer build stub f5d186ece18e1b0b992ccb870827a6b618c6c6df Merge commit 'stable/master'
First the good news: mplayer does play all samplerates very clear! Pure, lovely sinus ;-) access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 16384 OSS format: S16_LE OSS channels: 2 OSS rate: 48000 OSS period bytes: 4096 OSS periods: 16 OSS period frames: 1024
Now the bad:
Xine does not work... crackles horrible on all sample rates when run from cmd: xine 0_16_m_11025.wav
access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 2048 buffer_size: 16384
kind regards Bjoern
On Thu, Oct 30, 2008 at 11:46, Bjoern Olausson lkmlist@gmail.com wrote:
On Tue, Oct 28, 2008 at 15:12, Takashi Iwai tiwai@suse.de wrote:
Now the bad:
Xine does not work... crackles horrible on all sample rates when run from cmd: xine 0_16_m_11025.wav
access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 2048 buffer_size: 16384
kind regards Bjoern
mmh, I recompiled xine-lib without mmap support but I still get access: MMAP_INTERLEAVED
could mmap be a problem?
kind regards Bjoern
At Thu, 30 Oct 2008 12:05:12 +0100, Bjoern Olausson wrote:
On Thu, Oct 30, 2008 at 11:46, Bjoern Olausson lkmlist@gmail.com wrote:
On Tue, Oct 28, 2008 at 15:12, Takashi Iwai tiwai@suse.de wrote:
Now the bad:
Xine does not work... crackles horrible on all sample rates when run from cmd: xine 0_16_m_11025.wav
access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 2048 buffer_size: 16384
kind regards Bjoern
mmh, I recompiled xine-lib without mmap support but I still get access: MMAP_INTERLEAVED
Maybe it's accessed via alsa-plugin. What about let xine using "hw" PCM device instead of "default"? Then xine would play at 48kHz natively without conversions in alsa-lib.
could mmap be a problem?
Possible, can't determine exactly at this moment...
Takashi
On Thu, Oct 30, 2008 at 12:07, Takashi Iwai tiwai@suse.de wrote:
At Thu, 30 Oct 2008 12:05:12 +0100, Bjoern Olausson wrote:
On Thu, Oct 30, 2008 at 11:46, Bjoern Olausson lkmlist@gmail.com wrote:
On Tue, Oct 28, 2008 at 15:12, Takashi Iwai tiwai@suse.de wrote:
Now the bad:
Xine does not work... crackles horrible on all sample rates when run from cmd: xine 0_16_m_11025.wav
access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 2048 buffer_size: 16384
kind regards Bjoern
mmh, I recompiled xine-lib without mmap support but I still get access: MMAP_INTERLEAVED
Maybe it's accessed via alsa-plugin. What about let xine using "hw" PCM device instead of "default"? Then xine would play at 48kHz natively without conversions in alsa-lib.
mmh weird... xine works... Couldn't reproduce my previous report... thought I changed nothing... Please ignore the xine crackeling... seems not reproducable (If I can reproduce it, I'll let you know).
Bjoern
Hello,
I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and installed it for the x-fi driver.
The problem is, with pulseaudio, i get a pop every few seconds like, every 3 seconds, "pop" and it does it over and over and over
I seem to get no sound at all with the card if I bypass pulse
What can I do?
I killed pulseaudio and the problem is the same as far as every few seconds, just a different sound. it seems to be the xfi driver.
I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz however, I am trying to get away from that driver because of other issues.
Thanks!
On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
Hello,
I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and installed it for the x-fi driver.
The problem is, with pulseaudio, i get a pop every few seconds like, every 3 seconds, "pop" and it does it over and over and over
I seem to get no sound at all with the card if I bypass pulse
What can I do?
At Wed, 10 Jun 2009 03:52:35 -0500, Ted T. Logan wrote:
I killed pulseaudio and the problem is the same as far as every few seconds, just a different sound. it seems to be the xfi driver.
Please be more specific, what apps did you test and how, and on which hardware, with which alsa-driver. There is no svn alsa-driver at all, at least, as I know of.
If it's emu20k1 chip (not emu20k2), try use_system_timer=1 module option snd-ctxfi driver. This will take the timer management back to the old one using the system timer.
thanks,
Takashi
I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz however, I am trying to get away from that driver because of other issues.
Thanks!
On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
Hello, I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and installed it for the x-fi driver. The problem is, with pulseaudio, i get a pop every few seconds like, every 3 seconds, "pop" and it does it over and over and over I seem to get no sound at all with the card if I bypass pulse What can I do?
Sorry: ftp://kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.bz2
Every app I've tried it with:)
Sound Blaster X-Fi SB0670 PCI Sound Card with emu20k1 chipset.
On Wed, 2009-06-10 at 11:29 +0200, Takashi Iwai wrote:
At Wed, 10 Jun 2009 03:52:35 -0500, Ted T. Logan wrote:
I killed pulseaudio and the problem is the same as far as every few seconds, just a different sound. it seems to be the xfi driver.
Please be more specific, what apps did you test and how, and on which hardware, with which alsa-driver. There is no svn alsa-driver at all, at least, as I know of.
If it's emu20k1 chip (not emu20k2), try use_system_timer=1 module option snd-ctxfi driver. This will take the timer management back to the old one using the system timer.
thanks,
Takashi
I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz however, I am trying to get away from that driver because of other issues.
Thanks!
On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
Hello, I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and installed it for the x-fi driver. The problem is, with pulseaudio, i get a pop every few seconds like, every 3 seconds, "pop" and it does it over and over and over I seem to get no sound at all with the card if I bypass pulse What can I do?
same problem after I added those options. I'm listening to something in flash player right now and I have a click every 3 seconds.
On Wed, 2009-06-10 at 11:29 +0200, Takashi Iwai wrote:
At Wed, 10 Jun 2009 03:52:35 -0500, Ted T. Logan wrote:
I killed pulseaudio and the problem is the same as far as every few seconds, just a different sound. it seems to be the xfi driver.
Please be more specific, what apps did you test and how, and on which hardware, with which alsa-driver. There is no svn alsa-driver at all, at least, as I know of.
If it's emu20k1 chip (not emu20k2), try use_system_timer=1 module option snd-ctxfi driver. This will take the timer management back to the old one using the system timer.
thanks,
Takashi
I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz however, I am trying to get away from that driver because of other issues.
Thanks!
On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
Hello, I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and installed it for the x-fi driver. The problem is, with pulseaudio, i get a pop every few seconds like, every 3 seconds, "pop" and it does it over and over and over I seem to get no sound at all with the card if I bypass pulse What can I do?
Here's the output during some skipping. It happens with or without pulse if I have any application playing sound to my xfi. Do not have the same problem if output goes to integrated intel:
cat /proc/asound/card0/pcm0p/sub0/* access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 1 rate: 44100 (44100/1) period_size: 32768 buffer_size: 65536 card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: ctxfi name: Front/WaveIn subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 8 subdevices_avail: 7 128 128 state: RUNNING trigger_time: 74684.238387841 tstamp : 74702.900700135 delay : 2664 avail : 62872 avail_max : 62872 ----- hw_ptr : 822976 appl_ptr : 825640 tstamp_mode: ENABLE period_step: 1 avail_min: 63069 start_threshold: 4294967295 stop_threshold: 1073741824 silence_threshold: 0 silence_size: 0 boundary: 1073741824
On Wed, 2009-06-10 at 11:29 +0200, Takashi Iwai wrote:
At Wed, 10 Jun 2009 03:52:35 -0500, Ted T. Logan wrote:
I killed pulseaudio and the problem is the same as far as every few seconds, just a different sound. it seems to be the xfi driver.
Please be more specific, what apps did you test and how, and on which hardware, with which alsa-driver. There is no svn alsa-driver at all, at least, as I know of.
If it's emu20k1 chip (not emu20k2), try use_system_timer=1 module option snd-ctxfi driver. This will take the timer management back to the old one using the system timer.
thanks,
Takashi
I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz however, I am trying to get away from that driver because of other issues.
Thanks!
On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
Hello, I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and installed it for the x-fi driver. The problem is, with pulseaudio, i get a pop every few seconds like, every 3 seconds, "pop" and it does it over and over and over I seem to get no sound at all with the card if I bypass pulse What can I do?
Hello,
I do not have this problem with:
XFiDrv_Linux_Public_US_1.00.tar.gz
but I tried the latest driver from:
ftp://kernel.org/pub/linux/kernel/people/tiwai/snapshot/
and I get a "tick" every second or two during playback with ANY application.
Fedora 11. sb0670 emu20k1.
What to do?
participants (16)
-
Alexander E. Patrakov -
Bjoern Olausson -
Brendan Pike -
James Courtier-Dutton -
Jan Wolf -
Jason Harvey -
Pavel Hofman -
Takashi Iwai -
Ted T. Logan -
Ted T. Logian
-
The Source -
Thomas Scheunemann -
Vedran Miletić -
William Pitcock -
Xarteras
-
zhangal