Backported sbxfi driver (UNTESTED!)

Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Brendan Pike]

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

Re: Backported sbxfi driver (UNTESTED!)

[Ted T. Logian]

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

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 2097 bytes --]

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
> 

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Ted T. Logian]

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

Re: Backported sbxfi driver (UNTESTED!)

[James Courtier-Dutton]

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

Re: Backported sbxfi driver (UNTESTED!)

[Ted T. Logian]

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

Re: Backported sbxfi driver (UNTESTED!)

[Ted T. Logian]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Ted T. Logian]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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;
 }

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 2529 bytes --]

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
> 

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Fri, 10 Oct 2008 20:39:48 +0400,
The Source wrote:
> 
> 2008/10/10 Takashi Iwai <tiwai@suse.de>
> 
>     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
> 
> Hello, I have tried the driver with the fix you provided, but I couldn't get
> anything. Kernel panic on any attempt to use sound or mixer. Also kernel panic
> several seconds after Xorg starts. Each crash causes either hang or reboot so
> I couldn't get any error messages. If there are some logs left, please tell me
> where they are and I'll send them to you.
> My card is X-Fi Platinum Fatality Champion Series.

For testing, first try without X but just use Linux console, so that
you have a better chance to see Oops messages.  It's pretty important
to see whether it's an Oops or a panic.  Also, double-check whether
you really installed the corrected drivers.  Often it's missing in the
right place by stupid reasons.

For first tests, don't use any sound server.  Try with aplay like:
	% aplay -Dhw foo.wav
Try first 96kHz samples, 48kHz samples, and then others.


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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;

Re: Backported sbxfi driver (UNTESTED!)

[Ted T. Logian]

On Sat, 2008-10-11 at 17:47 +0200, Takashi Iwai wrote:

> At Fri, 10 Oct 2008 20:39:48 +0400,
> The Source wrote:
> > 
> > 2008/10/10 Takashi Iwai <tiwai@suse.de>
> > 
> >     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
> > 
> > Hello, I have tried the driver with the fix you provided, but I couldn't get
> > anything. Kernel panic on any attempt to use sound or mixer. Also kernel panic
> > several seconds after Xorg starts. Each crash causes either hang or reboot so
> > I couldn't get any error messages. If there are some logs left, please tell me
> > where they are and I'll send them to you.
> > My card is X-Fi Platinum Fatality Champion Series.
> 
> For testing, first try without X but just use Linux console, so that
> you have a better chance to see Oops messages.  It's pretty important
> to see whether it's an Oops or a panic.  Also, double-check whether
> you really installed the corrected drivers.  Often it's missing in the
> right place by stupid reasons.
> 
> For first tests, don't use any sound server.  Try with aplay like:
> 	% aplay -Dhw foo.wav
> Try first 96kHz samples, 48kHz samples, and then others.
> 
> 
> thanks,
> 
> Takashi



Tak,

I just wanted to make sure you knew of the different types of sbxfi
cards.

For instance, I have this one:
http://www.geeks.com/details.asp?invtid=SB0670-BULK&cat=SND

It's still emu20k1.  However, it is impossible to use with creative's
drivers, as it always causes a lockup, but it works with oss4 drivers.

I don't know if this matters to you at all, but I wanted to let you know
in case it affected how the driver progressed to be compatible with the
most emu20k1 cards.

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai ?????:
> At Fri, 10 Oct 2008 20:39:48 +0400,
> The Source wrote:
>   
>> 2008/10/10 Takashi Iwai <tiwai@suse.de>
>>
>>     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
>>
>> Hello, I have tried the driver with the fix you provided, but I couldn't get
>> anything. Kernel panic on any attempt to use sound or mixer. Also kernel panic
>> several seconds after Xorg starts. Each crash causes either hang or reboot so
>> I couldn't get any error messages. If there are some logs left, please tell me
>> where they are and I'll send them to you.
>> My card is X-Fi Platinum Fatality Champion Series.
>>     
>
> For testing, first try without X but just use Linux console, so that
> you have a better chance to see Oops messages.  It's pretty important
> to see whether it's an Oops or a panic.  Also, double-check whether
> you really installed the corrected drivers.  Often it's missing in the
> right place by stupid reasons.
>
> For first tests, don't use any sound server.  Try with aplay like:
> 	% aplay -Dhw foo.wav
> Try first 96kHz samples, 48kHz samples, and then others.
>
>
> thanks,
>
> Takashi
>
>   
aplay in console causes reboot, sorry.

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Sat, 11 Oct 2008 11:03:22 -0500,
Ted T. Logian wrote:
> 
> On Sat, 2008-10-11 at 17:47 +0200, Takashi Iwai wrote:
> 
>     At Fri, 10 Oct 2008 20:39:48 +0400,
>     The Source wrote:
>     > 
>     > 2008/10/10 Takashi Iwai <tiwai@suse.de>
>     > 
>     >     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
>     > 
>     > Hello, I have tried the driver with the fix you provided, but I couldn't get
>     > anything. Kernel panic on any attempt to use sound or mixer. Also kernel panic
>     > several seconds after Xorg starts. Each crash causes either hang or reboot so
>     > I couldn't get any error messages. If there are some logs left, please tell me
>     > where they are and I'll send them to you.
>     > My card is X-Fi Platinum Fatality Champion Series.
>     
>     For testing, first try without X but just use Linux console, so that
>     you have a better chance to see Oops messages.  It's pretty important
>     to see whether it's an Oops or a panic.  Also, double-check whether
>     you really installed the corrected drivers.  Often it's missing in the
>     right place by stupid reasons.
>     
>     For first tests, don't use any sound server.  Try with aplay like:
>             % aplay -Dhw foo.wav
>     Try first 96kHz samples, 48kHz samples, and then others.
> 
>     thanks,
>     
>     Takashi
> 
> Tak,
> 
> I just wanted to make sure you knew of the different types of sbxfi cards.

Yeah, especially Vista-compatible cards require a very strange
initialization sequence, as you find in the source code...

> For instance, I have this one:
> http://www.geeks.com/details.asp?invtid=SB0670-BULK&cat=SND
> 
> It's still emu20k1.  However, it is impossible to use with creative's drivers,
> as it always causes a lockup, but it works with oss4 drivers.

Does it lock after loading the driver?
If not, what does /proc/asound/cards shows?  Also, show the output of
"lspci -nv" for the device, and "lspci -xvvv" before and after loading
the driver.

I'm afraid it's UAA (vista-compatible) type.  If so, maybe something
is wrong in the initialization, or it takes a wrong port address
(BAR), etc...

> I don't know if this matters to you at all, but I wanted to let you know in
> case it affected how the driver progressed to be compatible with the most
> emu20k1 cards.

Indeed, there are really different models with emu20k1...


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Sat, 11 Oct 2008 20:28:23 +0400,
The Source wrote:
> 
> Takashi Iwai ?????:
> > At Fri, 10 Oct 2008 20:39:48 +0400,
> > The Source wrote:
> >   
> >> 2008/10/10 Takashi Iwai <tiwai@suse.de>
> >>
> >>     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
> >>
> >> Hello, I have tried the driver with the fix you provided, but I couldn't get
> >> anything. Kernel panic on any attempt to use sound or mixer. Also kernel panic
> >> several seconds after Xorg starts. Each crash causes either hang or reboot so
> >> I couldn't get any error messages. If there are some logs left, please tell me
> >> where they are and I'll send them to you.
> >> My card is X-Fi Platinum Fatality Champion Series.
> >>     
> >
> > For testing, first try without X but just use Linux console, so that
> > you have a better chance to see Oops messages.  It's pretty important
> > to see whether it's an Oops or a panic.  Also, double-check whether
> > you really installed the corrected drivers.  Often it's missing in the
> > right place by stupid reasons.
> >
> > For first tests, don't use any sound server.  Try with aplay like:
> > 	% aplay -Dhw foo.wav
> > Try first 96kHz samples, 48kHz samples, and then others.
> >
> >
> > thanks,
> >
> > Takashi
> >
> >   
> aplay in console causes reboot, sorry.

OK, then this sounds like the same symptom as Ted's.
Could you give the information described in my last followup to Ted's
post? 


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 5024 bytes --]

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
> 

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 5636 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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
> > 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 2392 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Vedran Miletić]

What does this mean? That there are X-Fi cards which aren't Vista-compatible?
Also, shouldn't UAA cards work with hda-intel driver with specific
patch for Creative?

2008/10/11 Takashi Iwai <tiwai@suse.de>:
> At Sat, 11 Oct 2008 11:03:22 -0500,
> Ted T. Logian wrote:
>>
>> On Sat, 2008-10-11 at 17:47 +0200, Takashi Iwai wrote:
>>
>>     At Fri, 10 Oct 2008 20:39:48 +0400,
>>     The Source wrote:
>>     >
>>     > 2008/10/10 Takashi Iwai <tiwai@suse.de>
>>     >
>>     >     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
>>     >
>>     > Hello, I have tried the driver with the fix you provided, but I couldn't get
>>     > anything. Kernel panic on any attempt to use sound or mixer. Also kernel panic
>>     > several seconds after Xorg starts. Each crash causes either hang or reboot so
>>     > I couldn't get any error messages. If there are some logs left, please tell me
>>     > where they are and I'll send them to you.
>>     > My card is X-Fi Platinum Fatality Champion Series.
>>
>>     For testing, first try without X but just use Linux console, so that
>>     you have a better chance to see Oops messages.  It's pretty important
>>     to see whether it's an Oops or a panic.  Also, double-check whether
>>     you really installed the corrected drivers.  Often it's missing in the
>>     right place by stupid reasons.
>>
>>     For first tests, don't use any sound server.  Try with aplay like:
>>             % aplay -Dhw foo.wav
>>     Try first 96kHz samples, 48kHz samples, and then others.
>>
>>     thanks,
>>
>>     Takashi
>>
>> Tak,
>>
>> I just wanted to make sure you knew of the different types of sbxfi cards.
>
> Yeah, especially Vista-compatible cards require a very strange
> initialization sequence, as you find in the source code...
>
>> For instance, I have this one:
>> http://www.geeks.com/details.asp?invtid=SB0670-BULK&cat=SND
>>
>> It's still emu20k1.  However, it is impossible to use with creative's drivers,
>> as it always causes a lockup, but it works with oss4 drivers.
>
> Does it lock after loading the driver?
> If not, what does /proc/asound/cards shows?  Also, show the output of
> "lspci -nv" for the device, and "lspci -xvvv" before and after loading
> the driver.
>
> I'm afraid it's UAA (vista-compatible) type.  If so, maybe something
> is wrong in the initialization, or it takes a wrong port address
> (BAR), etc...
>
>> I don't know if this matters to you at all, but I wanted to let you know in
>> case it affected how the driver progressed to be compatible with the most
>> emu20k1 cards.
>
> Indeed, there are really different models with emu20k1...
>
>
> thanks,
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>



-- 
Vedran Miletić
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[James Courtier-Dutton]

Takashi Iwai wrote:
> 
> I'm afraid it's UAA (vista-compatible) type.  If so, maybe something
> is wrong in the initialization, or it takes a wrong port address
> (BAR), etc...
> 

The BARs change when one switches from UAA (the default on some cards)
to XFi mode. You will probably have to provide some method for
correcting this after the change.

Kind Regards

James

Re: Backported sbxfi driver (UNTESTED!)

[James Courtier-Dutton]

Vedran Miletić wrote:
> What does this mean? That there are X-Fi cards which aren't Vista-compatible?
> Also, shouldn't UAA cards work with hda-intel driver with specific
> patch for Creative?
> 

X-Fi cards that are Vista compatible boot up in hda-intel mode, so yes,
we could provide support in the hda-intel driver for them.
The features would be limited, but the user would get some sound.

Kind Regards

James

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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

James Courtier-Dutton пишет:
> Vedran Miletić wrote:
>   
>> What does this mean? That there are X-Fi cards which aren't Vista-compatible?
>> Also, shouldn't UAA cards work with hda-intel driver with specific
>> patch for Creative?
>>
>>     
>
> X-Fi cards that are Vista compatible boot up in hda-intel mode, so yes,
> we could provide support in the hda-intel driver for them.
> The features would be limited, but the user would get some sound.
>
> Kind Regards
>
> James
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>   
Attaching files you requested.
I don't have 96000Hz samples, tried 22KHz - reboot.
Attempt to load module while Xorg is running causes reboot.
Note that you should use latest mercurial oss to port - earlier versions 
have conflict with drivers like nvidia.
alsamixer shows only master but that probably because asound.conf 
deosn't contain needed info (I usually use system-config-soundcard to 
write all that needed to asound.conf but I can't do it since Xorg with 
sbxfi don't work).

[-- Attachment #2: info.tar.bz2 --]
[-- Type: application/x-bzip, Size: 7391 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

Hi,

I have just compiled driver from git and try to run it. My card is pci:
1102:0005 Multimedia audio controller: Creative Labs SB X-Fi

I got following:

root@mayonaka:~# modprobe snd-sbxfi
root@mayonaka:~# speaker-test -c 2 -r 96000 -t sine

speaker-test 1.0.15

Playback device is default
Stream parameters are 96000Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 96000Hz (requested 96000Hz)
[  262.522739] XFi DAC reset timeout

Period size ran[  262.564029] XFi DAC reset timeout
ge from 32 to 16[  262.620275] XFi DAC reset timeout
384
Using max b[  262.676529] XFi DAC reset timeout
uffer size 16384[  262.732784] XFi DAC reset timeout

Periods = 4
w[  262.789038] XFi DAC reset timeout
as set period_size = 4096
was set buffer_size = 16384
 0 - Front Left
[  327.491997] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
[  327.492001] Kernel panic - not syncing: softlockup: hung tasks

and i did hear the sine on the left channel. Hope it helps...

-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Sun, 12 Oct 2008 16:53:53 +0400,
Alexey Bazhin wrote:
> 
> Hi,
> 
> I have just compiled driver from git and try to run it. My card is pci:
> 1102:0005 Multimedia audio controller: Creative Labs SB X-Fi
> 
> I got following:
> 
> root@mayonaka:~# modprobe snd-sbxfi
> root@mayonaka:~# speaker-test -c 2 -r 96000 -t sine
> 
> speaker-test 1.0.15
> 
> Playback device is default
> Stream parameters are 96000Hz, S16_LE, 2 channels
> Sine wave rate is 440.0000Hz
> Rate set to 96000Hz (requested 96000Hz)
> [  262.522739] XFi DAC reset timeout
> 
> Period size ran[  262.564029] XFi DAC reset timeout
> ge from 32 to 16[  262.620275] XFi DAC reset timeout
> 384
> Using max b[  262.676529] XFi DAC reset timeout
> uffer size 16384[  262.732784] XFi DAC reset timeout
> 
> Periods = 4
> w[  262.789038] XFi DAC reset timeout
> as set period_size = 4096
> was set buffer_size = 16384
>  0 - Front Left
> [  327.491997] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> [  327.492001] Kernel panic - not syncing: softlockup: hung tasks
> 
> and i did hear the sine on the left channel. Hope it helps...

Try the very latest sound-unstable tree.  Some fixes are there...


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Sun, 12 Oct 2008 20:16:10 -0500,
Christopher Lemire wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sun, Oct 12, 2008 at 2:34 PM, Takashi Iwai  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?
> >
> > 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
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> 
> Would someone mind telling me how I can put my card in hda-intel mode
> and use the snd-hda-intel driver with it? I read it was possible to do
> that with the creative windows software but didn't see that anywhere.
> Is there any reason I shouldn't do that? Do I really need any Xfi
> driver when I can do that? My Xfi card is a newer one that should have
> the hda-intel mode. It's Vista compatible (though I use it dual boot
> with xp) and a newer PCIe model called Titanium. It's newer than the
> Creative Linux beta driver, so it will not work with that or OSS4. I
> just removed OSS4 and going back to Alsa to test that snd-sbxfi
> because OSS4 would crash my computer with this sound card. I think the
> OSS4 was written for older Xfi models, not this newer PCIe model I
> have. Chances of me getting it to work in Linux aren't good, so I'll
> probably be doing a RMA on it in the next few days before I run out of
> time to do that and going back to using onboard audio.

The sound-unstable tree contains the HD-audio X-Fi support, but right
now it's disabled due to possible conflicts of drivers.
Just uncomment the corresponding entries in PCI entries of
sound/pci/hda_intel.c.


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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=shortlog;h=topic/sbxfi


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Sun, 12 Oct 2008 09:44:37 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > 
> > I'm afraid it's UAA (vista-compatible) type.  If so, maybe something
> > is wrong in the initialization, or it takes a wrong port address
> > (BAR), etc...
> > 
> 
> The BARs change when one switches from UAA (the default on some cards)
> to XFi mode. You will probably have to provide some method for
> correcting this after the change.

The OSS driver seems to overwrite the old values of BAR1-5...


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

On Mon, 13 Oct 2008 04:03:34 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Sun, 12 Oct 2008 16:53:53 +0400,
> Alexey Bazhin wrote:
> > 
> > Hi,
> > 
> > I have just compiled driver from git and try to run it. My card is
> > pci: 1102:0005 Multimedia audio controller: Creative Labs SB X-Fi
> > 
> > I got following:
> > 
> > root@mayonaka:~# modprobe snd-sbxfi
> > root@mayonaka:~# speaker-test -c 2 -r 96000 -t sine
> > 
> > speaker-test 1.0.15
> > 
> > Playback device is default
> > Stream parameters are 96000Hz, S16_LE, 2 channels
> > Sine wave rate is 440.0000Hz
> > Rate set to 96000Hz (requested 96000Hz)
> > [  262.522739] XFi DAC reset timeout
> > 
> > Period size ran[  262.564029] XFi DAC reset timeout
> > ge from 32 to 16[  262.620275] XFi DAC reset timeout
> > 384
> > Using max b[  262.676529] XFi DAC reset timeout
> > uffer size 16384[  262.732784] XFi DAC reset timeout
> > 
> > Periods = 4
> > w[  262.789038] XFi DAC reset timeout
> > as set period_size = 4096
> > was set buffer_size = 16384
> >  0 - Front Left
> > [  327.491997] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> > [  327.492001] Kernel panic - not syncing: softlockup: hung tasks
> > 
> > and i did hear the sine on the left channel. Hope it helps...
> 
> Try the very latest sound-unstable tree.  Some fixes are there...
Without debug i got the same, with debug my box freezed without
panic, i'l reset it when i get home and will try it again...

root@mayonaka:~# modprobe snd_sbxfi
root@mayonaka:~# dmesg -n 8
root@mayonaka:~# echo 3 > /sys/module/snd_sbxfi/parameters/debug 
root@mayonaka:~# speaker-test -c 2 -r 96000 -t sine

speaker-test 1.0.15

Playback device is default
Stream parameters are 96000Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 96000Hz (requested 96000Hz)
Buffer size range from 32 to 16384
Period size range from 32 to 16384
Using max buffer size 16384
Periods = 4
was set period_size = 4096
was set buffer_size = 16384

and on serial console:

root@mayonaka:~# [  260.267198] SBXFI: read(0) 0x1c6010 = 0x400
[  260.317211] SBXFI: IRQ = 0x400
[  260.353691] SBXFI: write(0) 0x1c6010 = 0x400
[  260.405119] SBXFI: read(0) 0x1c6010 = 0x400
[  260.455132] SBXFI: IRQ = 0x400
[  260.491612] SBXFI: write(0) 0x1c6010 = 0x400
[  260.548382] SBXFI: read(0) 0x1c6010 = 0x400
[  260.598458] SBXFI: IRQ = 0x400
[  260.634936] SBXFI: write(0) 0x1c6010 = 0x400
[  260.707256] SBXFI: Allocate SRC 0
[  260.747893] SBXFI: allocated TLB at 0 for 16 pages
[  260.805192] SBXFI: filled TLB pages starting at 0xc10000
[  260.869274] SBXFI: PLAYBACK PREPARE: rate=96000, period_size=4096,
buffer_size=16384
[  260.961916] SBXFI: read(0) 0x1c6010 = 0x400
[  261.011901] SBXFI: IRQ = 0x400
[  261.048383] SBXFI: write(0) 0x1c6010 = 0x400
[  261.099457] SBXFI: INIT DAC
[  261.132903] SBXFI: read(0) 0x1c6020 = 0x9e00
[  261.184021] SBXFI: write(0) 0x1c6020 = 0x9e00
[  261.236091] SBXFI: RESET DAC
[  261.270491] SBXFI: write(10) 0xcc = 0x8c
[  261.317366] SBXFI: write(10) 0xcc = 0xe
[  261.363203] SBXFI: read(10) 0xcc = 0x83aa
[  261.411115] SBXFI: read(10) 0xcc = 0x83aa
[  261.459022] SBXFI: write(10) 0xec = 0x5
[  261.504863] SBXFI: read(10) 0xec = 0x80800005
[  261.656093] SBXFI: read(0) 0x1c6020 = 0x9e00
[  261.707117] SBXFI: write(0) 0x1c6020 = 0x9e00
[  261.759192] SBXFI: read(0) 0x1c6020 = 0x9e00
[  261.811209] SBXFI: write(0) 0x1c6020 = 0x9e02
[  261.962494] SBXFI: read(0) 0x1c6020 = 0x9e02
[  262.013614] SBXFI: write(0) 0x1c6020 = 0x9e00
[  262.065688] SBXFI: read(0) 0x1c6020 = 0x9e00
[  262.117708] SBXFI: write(0) 0x1c6020 = 0x9e02
[  262.169826] SBXFI: write(10) 0xe0 = 0x180080
[  262.220860] SBXFI: write(10) 0xe4 = 0x8001
[  262.269812] SBXFI: read(10) 0xec = 0x80000005
[  262.321881] XFi DAC reset timeout
[  262.361479] SBXFI: write(10) 0xe0 = 0x180080
[  262.412511] SBXFI: write(10) 0xe4 = 0x1002
[  262.461466] SBXFI: read(10) 0xec = 0x80000005
[  262.513533] XFi DAC reset timeout
[  262.553132] SBXFI: write(10) 0xe0 = 0x180080
[  262.604164] SBXFI: write(10) 0xe4 = 0x2506
[  262.653117] SBXFI: read(10) 0xec = 0x80000005
[  262.705185] XFi DAC reset timeout
[  262.744783] SBXFI: write(10) 0xe0 = 0x180080
[  262.795817] SBXFI: write(10) 0xe4 = 0x2509
[  262.844772] SBXFI: read(10) 0xec = 0x80000005
[  262.896838] XFi DAC reset timeout
[  262.936436] SBXFI: write(10) 0xe0 = 0x180080
[  262.987469] SBXFI: write(10) 0xe4 = 0x250c
[  263.036422] SBXFI: read(10) 0xec = 0x80000005
[  263.088489] XFi DAC reset timeout
[  263.128091] SBXFI: write(10) 0xe0 = 0x180080
[  263.179122] SBXFI: write(10) 0xe4 = 0x250f
[  263.228076] SBXFI: read(10) 0xec = 0x80000005
[  263.280144] XFi DAC reset timeout
[  263.319744] SBXFI: read(0) 0x1c6020 = 0x9e02
[  263.370774] SBXFI: write(0) 0x1c6020 = 0x9e42
[  263.422847] SBXFI: SETUP I2S
[  263.457246] SBXFI: read(0) 0x1c5420 = 0x0
[  263.505154] SBXFI: write(0) 0x1c5420 = 0x4040406
[  263.560353] SBXFI: Pitch [0:fa6] = 0x1000000
[  263.611381] SBXFI: write(0) 0x19be98 = 0x1000000
[  263.666569] SBXFI: Pitch [80:7a6] = 0x1000000
[  263.718632] SBXFI: write(0) 0x199e98 = 0x1000000
[  263.773831] SBXFI: Pitch [1:fb6] = 0x1000000
[  263.824859] SBXFI: write(0) 0x19bed8 = 0x1000000
[  263.880048] SBXFI: Pitch [81:7b6] = 0x1000000
[  263.932118] SBXFI: write(0) 0x199ed8 = 0x1000000
[  263.987308] SBXFI: Amp [0:1] = 0xeb1
[  264.030021] SBXFI: write(0) 0x140008 = 0x3ac40011
[  264.086250] SBXFI: write(0) 0x14000c = 0x0
[  264.135203] SBXFI: write(0) 0x143d30 = 0x3ac47a61
[  264.191432] SBXFI: write(0) 0x143d34 = 0x0
[  264.240384] SBXFI: Amp [80:7a6] = 0xeb1
[  264.286217] SBXFI: Amp [1:11] = 0xeb1
[  264.329973] SBXFI: write(0) 0x140088 = 0x3ac40111
[  264.386201] SBXFI: write(0) 0x14008c = 0x0
[  264.435156] SBXFI: write(0) 0x143db0 = 0x3ac47b61
[  264.491383] SBXFI: write(0) 0x143db4 = 0x0
[  264.540334] SBXFI: Amp [81:7b6] = 0xeb1
[  264.586169] SBXFI: write(0) 0x1c5000 = 0x0
[  264.635122] SBXFI: write(0) 0x1c5004 = 0x0
[  264.684074] SBXFI: write(0) 0x1c5008 = 0x0
[  264.733026] SBXFI: write(0) 0x1c500c = 0x0
[  264.781978] SBXFI: write(0) 0x1c5010 = 0x0
[  264.830930] SBXFI: write(0) 0x1c5014 = 0x0
[  264.879885] SBXFI: write(0) 0x1c5018 = 0x0
[  264.928838] SBXFI: write(0) 0x1c501c = 0x0
[  264.977790] SBXFI: write(0) 0x1c5020 = 0x0
[  265.026743] SBXFI: write(0) 0x1c5024 = 0x0
[  265.075695] SBXFI: write(0) 0x1c5028 = 0x0
[  265.124646] SBXFI: write(0) 0x1c502c = 0x0
[  265.173599] SBXFI: write(0) 0x1c5030 = 0x0
[  265.222553] SBXFI: write(0) 0x1c5034 = 0x0
[  265.271503] SBXFI: write(0) 0x1c5038 = 0x0
[  265.320458] SBXFI: write(0) 0x1c503c = 0x0
[  265.369409] SBXFI: write(0) 0x1c5040 = 0x0
[  265.418369] SBXFI: write(0) 0x1c5044 = 0x0
[  265.467314] SBXFI: write(0) 0x1c5048 = 0x0
[  265.516267] SBXFI: write(0) 0x1c504c = 0x0
[  265.565221] SBXFI: write(0) 0x1c5050 = 0x0
[  265.614172] SBXFI: write(0) 0x1c5054 = 0x0
[  265.663124] SBXFI: write(0) 0x1c5058 = 0x0
[  265.712076] SBXFI: write(0) 0x1c505c = 0x0
[  265.761032] SBXFI: write(0) 0x1c5060 = 0x0
[  265.809982] SBXFI: write(0) 0x1c5064 = 0x0
[  265.858936] SBXFI: write(0) 0x1c5068 = 0x0
[  265.907889] SBXFI: write(0) 0x1c506c = 0x0
[  265.956840] SBXFI: write(0) 0x1c5070 = 0x0
[  266.005793] SBXFI: write(0) 0x1c5074 = 0x0
[  266.054745] SBXFI: write(0) 0x1c5078 = 0x0
[  266.103696] SBXFI: write(0) 0x1c507c = 0x0
[  266.152649] SBXFI: write(0) 0x1c5080 = 0x0
[  266.201601] SBXFI: write(0) 0x1c5084 = 0x0
[  266.250554] SBXFI: write(0) 0x1c5088 = 0x0
[  266.299509] SBXFI: write(0) 0x1c508c = 0x0
[  266.348459] SBXFI: write(0) 0x1c5090 = 0x0
[  266.397412] SBXFI: write(0) 0x1c5094 = 0x0
[  266.446366] SBXFI: write(0) 0x1c5098 = 0x0
[  266.495317] SBXFI: write(0) 0x1c509c = 0x0
[  266.544270] SBXFI: write(0) 0x1c50a0 = 0x0
[  266.593224] SBXFI: write(0) 0x1c50a4 = 0x0
[  266.642175] SBXFI: write(0) 0x1c50a8 = 0x0
[  266.691125] SBXFI: write(0) 0x1c50ac = 0x0
[  266.740081] SBXFI: write(0) 0x1c50b0 = 0x0
[  266.789032] SBXFI: write(0) 0x1c50b4 = 0x0
[  266.837985] SBXFI: write(0) 0x1c50b8 = 0x0
[  266.886938] SBXFI: write(0) 0x1c50bc = 0x0
[  266.935891] SBXFI: write(0) 0x1c50c0 = 0x0
[  266.984842] SBXFI: write(0) 0x1c50c4 = 0x0
[  267.033795] SBXFI: write(0) 0x1c50c8 = 0x0
[  267.082748] SBXFI: write(0) 0x1c50cc = 0x0
[  267.131702] SBXFI: write(0) 0x1c50d0 = 0x0
[  267.180650] SBXFI: write(0) 0x1c50d4 = 0x0
[  267.229604] SBXFI: write(0) 0x1c50d8 = 0x0
[  267.278557] SBXFI: write(0) 0x1c50dc = 0x0
[  267.327508] SBXFI: write(0) 0x1c50e0 = 0x0
[  267.376462] SBXFI: write(0) 0x1c50e4 = 0x0
[  267.425415] SBXFI: write(0) 0x1c50e8 = 0x0
[  267.474367] SBXFI: write(0) 0x1c50ec = 0x0
[  267.523322] SBXFI: write(0) 0x1c50f0 = 0x0
[  267.572273] SBXFI: write(0) 0x1c50f4 = 0x0
[  267.621225] SBXFI: write(0) 0x1c50f8 = 0x0
[  267.670179] SBXFI: write(0) 0x1c50fc = 0x0
[  267.719130] SBXFI: write(0) 0x1c5100 = 0x0
[  267.768082] SBXFI: write(0) 0x1c5104 = 0x0
[  267.817034] SBXFI: write(0) 0x1c5108 = 0x0
[  267.865989] SBXFI: write(0) 0x1c510c = 0x0
[  267.914942] SBXFI: write(0) 0x1c5110 = 0x0
[  267.963894] SBXFI: write(0) 0x1c5114 = 0x0
[  268.012846] SBXFI: write(0) 0x1c5118 = 0x0
[  268.061798] SBXFI: write(0) 0x1c511c = 0x0
[  268.110749] SBXFI: write(0) 0x1c5120 = 0x0
[  268.159704] SBXFI: write(0) 0x1c5124 = 0x0
[  268.208656] SBXFI: write(0) 0x1c5128 = 0x0
[  268.257607] SBXFI: write(0) 0x1c512c = 0x0
[  268.306561] SBXFI: write(0) 0x1c5130 = 0x0
[  268.355513] SBXFI: write(0) 0x1c5134 = 0x0
[  268.404467] SBXFI: write(0) 0x1c5138 = 0x0
[  268.453418] SBXFI: write(0) 0x1c513c = 0x0
[  268.502370] SBXFI: write(0) 0x1c5000 = 0x0
[  268.551323] SBXFI: write(0) 0x1c5004 = 0x20011
[  268.604433] SBXFI: write(0) 0x1c5008 = 0x30801
[  268.657544] SBXFI: write(0) 0x1c500c = 0x811
[  268.708573] SBXFI: write(0) 0x1c5000 = 0x10001
[  268.761993] SBXFI: read(0) 0x1c6010 = 0x400
[  268.811984] SBXFI: IRQ = 0x400
[  268.848461] SBXFI: write(0) 0x1c6010 = 0x400
[  268.948453] SBXFI: PLAT TRIGGER START
[  268.952005] SBXFI: write(0) 0x1b0010 = 0x80
[  268.952005] SBXFI: write(0) 0x1b0014 = 0x0
[  268.952005] SBXFI: write(0) 0x1b0018 = 0x0
[  268.952005] SBXFI: write(0) 0x1b001c = 0x10000
[  268.952005] SBXFI: write(0) 0x1b0004 = 0x100
[  268.952005] SBXFI: write(0) 0x1b0000 = 0x1045c
[  268.952005] SBXFI: write(0) 0x1b0110 = 0x80
[  268.952005] SBXFI: write(0) 0x1b0114 = 0x0
[  268.952005] SBXFI: write(0) 0x1b0118 = 0x0
[  268.952005] SBXFI: write(0) 0x1b011c = 0x10000
[  268.952005] SBXFI: write(0) 0x1b0104 = 0x100
[  268.952005] SBXFI: write(0) 0x1b0100 = 0x5c
[  268.952005] SBXFI: read(0) 0x1b0010 = 0xc5b4
[  268.952005] SBXFI: POINTER = 314d
[  268.952005] SBXFI: set timer ticks = 20813
[  268.952005] SBXFI: write(0) 0x1c6004 = 0xdfff
[  268.952005] SBXFI: write(0) 0x1c6014 = 0x100


-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Mon, 13 Oct 2008 16:58:05 +0400,
Alexey Bazhin wrote:
> 
> On Mon, 13 Oct 2008 04:03:34 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Sun, 12 Oct 2008 16:53:53 +0400,
> > Alexey Bazhin wrote:
> > > 
> > > Hi,
> > > 
> > > I have just compiled driver from git and try to run it. My card is
> > > pci: 1102:0005 Multimedia audio controller: Creative Labs SB X-Fi
> > > 
> > > I got following:
> > > 
> > > root@mayonaka:~# modprobe snd-sbxfi
> > > root@mayonaka:~# speaker-test -c 2 -r 96000 -t sine
> > > 
> > > speaker-test 1.0.15
> > > 
> > > Playback device is default
> > > Stream parameters are 96000Hz, S16_LE, 2 channels
> > > Sine wave rate is 440.0000Hz
> > > Rate set to 96000Hz (requested 96000Hz)
> > > [  262.522739] XFi DAC reset timeout
> > > 
> > > Period size ran[  262.564029] XFi DAC reset timeout
> > > ge from 32 to 16[  262.620275] XFi DAC reset timeout
> > > 384
> > > Using max b[  262.676529] XFi DAC reset timeout
> > > uffer size 16384[  262.732784] XFi DAC reset timeout
> > > 
> > > Periods = 4
> > > w[  262.789038] XFi DAC reset timeout
> > > as set period_size = 4096
> > > was set buffer_size = 16384
> > >  0 - Front Left
> > > [  327.491997] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> > > [  327.492001] Kernel panic - not syncing: softlockup: hung tasks
> > > 
> > > and i did hear the sine on the left channel. Hope it helps...
> > 
> > Try the very latest sound-unstable tree.  Some fixes are there...
> Without debug i got the same, with debug my box freezed without
> panic, i'l reset it when i get home and will try it again...

Try the latest version.  Another fix was there.


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Mon, 13 Oct 2008 16:58:05 +0400,
> Alexey Bazhin wrote:
>   
>> On Mon, 13 Oct 2008 04:03:34 +0200
>> Takashi Iwai <tiwai@suse.de> wrote:
>>
>>     
>>> At Sun, 12 Oct 2008 16:53:53 +0400,
>>> Alexey Bazhin wrote:
>>>       
>>>> Hi,
>>>>
>>>> I have just compiled driver from git and try to run it. My card is
>>>> pci: 1102:0005 Multimedia audio controller: Creative Labs SB X-Fi
>>>>
>>>> I got following:
>>>>
>>>> root@mayonaka:~# modprobe snd-sbxfi
>>>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t sine
>>>>
>>>> speaker-test 1.0.15
>>>>
>>>> Playback device is default
>>>> Stream parameters are 96000Hz, S16_LE, 2 channels
>>>> Sine wave rate is 440.0000Hz
>>>> Rate set to 96000Hz (requested 96000Hz)
>>>> [  262.522739] XFi DAC reset timeout
>>>>
>>>> Period size ran[  262.564029] XFi DAC reset timeout
>>>> ge from 32 to 16[  262.620275] XFi DAC reset timeout
>>>> 384
>>>> Using max b[  262.676529] XFi DAC reset timeout
>>>> uffer size 16384[  262.732784] XFi DAC reset timeout
>>>>
>>>> Periods = 4
>>>> w[  262.789038] XFi DAC reset timeout
>>>> as set period_size = 4096
>>>> was set buffer_size = 16384
>>>>  0 - Front Left
>>>> [  327.491997] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
>>>> [  327.492001] Kernel panic - not syncing: softlockup: hung tasks
>>>>
>>>> and i did hear the sine on the left channel. Hope it helps...
>>>>         
>>> Try the very latest sound-unstable tree.  Some fixes are there...
>>>       
>> Without debug i got the same, with debug my box freezed without
>> panic, i'l reset it when i get home and will try it again...
>>     
>
> Try the latest version.  Another fix was there.
>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>   

Tried today's snapshot for my card (X-Fi Fatality Champion Series). No 
change. alsamixer shows only master and mic-boots for playback. Any 
attempt to use sound with alsa (aplay, any app that uses sound) results 
in reboot.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Mon, 13 Oct 2008 18:33:48 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Mon, 13 Oct 2008 16:58:05 +0400,
> > Alexey Bazhin wrote:
> >   
> >> On Mon, 13 Oct 2008 04:03:34 +0200
> >> Takashi Iwai <tiwai@suse.de> wrote:
> >>
> >>     
> >>> At Sun, 12 Oct 2008 16:53:53 +0400,
> >>> Alexey Bazhin wrote:
> >>>       
> >>>> Hi,
> >>>>
> >>>> I have just compiled driver from git and try to run it. My card is
> >>>> pci: 1102:0005 Multimedia audio controller: Creative Labs SB X-Fi
> >>>>
> >>>> I got following:
> >>>>
> >>>> root@mayonaka:~# modprobe snd-sbxfi
> >>>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t sine
> >>>>
> >>>> speaker-test 1.0.15
> >>>>
> >>>> Playback device is default
> >>>> Stream parameters are 96000Hz, S16_LE, 2 channels
> >>>> Sine wave rate is 440.0000Hz
> >>>> Rate set to 96000Hz (requested 96000Hz)
> >>>> [  262.522739] XFi DAC reset timeout
> >>>>
> >>>> Period size ran[  262.564029] XFi DAC reset timeout
> >>>> ge from 32 to 16[  262.620275] XFi DAC reset timeout
> >>>> 384
> >>>> Using max b[  262.676529] XFi DAC reset timeout
> >>>> uffer size 16384[  262.732784] XFi DAC reset timeout
> >>>>
> >>>> Periods = 4
> >>>> w[  262.789038] XFi DAC reset timeout
> >>>> as set period_size = 4096
> >>>> was set buffer_size = 16384
> >>>>  0 - Front Left
> >>>> [  327.491997] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> >>>> [  327.492001] Kernel panic - not syncing: softlockup: hung tasks
> >>>>
> >>>> and i did hear the sine on the left channel. Hope it helps...
> >>>>         
> >>> Try the very latest sound-unstable tree.  Some fixes are there...
> >>>       
> >> Without debug i got the same, with debug my box freezed without
> >> panic, i'l reset it when i get home and will try it again...
> >>     
> >
> > Try the latest version.  Another fix was there.
> >
> >
> > Takashi
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> >   
> 
> Tried today's snapshot for my card (X-Fi Fatality Champion Series). No 
> change.

Does the patch below already in your snapshot tarball?
Otherwise it's an older version.

> alsamixer shows only master and mic-boots for playback.

This is no bug.  It is so.  The OSS drivers doesn't provide more than
that, and thus mine, too.

> Any 
> attempt to use sound with alsa (aplay, any app that uses sound) results 
> in reboot.

This must be fixed, of course.  And I hoped that was the patch below.


Takashi

===
commit 80e25366431dd8a4481880d34072cd8de3c17376
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 13 03:59:45 2008 +0200

    sbxfi - fix spinlock again
    
    The last fix was broken; one shouldn't work on Sunday, really.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
index f4e8da1..39dfd9e 100644
--- a/sound/pci/sbxfi/sbxfi.c
+++ b/sound/pci/sbxfi/sbxfi.c
@@ -356,10 +356,10 @@ static irqreturn_t sbxfi_interrupt(int irq, void *dev_id)
 			spin_unlock(&chip->timer_lock);
 			if (update)
 				sbxfi_check_period_update(chip);
-			spin_unlock(&chip->timer_lock);
+			spin_lock(&chip->timer_lock);
 		} while (chip->timer_reprogram);
 		chip->irq_handling = 0;
-		spin_lock(&chip->timer_lock);
+		spin_unlock(&chip->timer_lock);
 	}
 
 	/* ack */
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Mon, 13 Oct 2008 16:56:28 +0200,
私 wrote:
> 
> At Mon, 13 Oct 2008 18:33:48 +0400,
> The Source wrote:
> > 
> > Takashi Iwai пишет:
> > > At Mon, 13 Oct 2008 16:58:05 +0400,
> > > Alexey Bazhin wrote:
> > >   
> > >> On Mon, 13 Oct 2008 04:03:34 +0200
> > >> Takashi Iwai <tiwai@suse.de> wrote:
> > >>
> > >>     
> > >>> At Sun, 12 Oct 2008 16:53:53 +0400,
> > >>> Alexey Bazhin wrote:
> > >>>       
> > >>>> Hi,
> > >>>>
> > >>>> I have just compiled driver from git and try to run it. My card is
> > >>>> pci: 1102:0005 Multimedia audio controller: Creative Labs SB X-Fi
> > >>>>
> > >>>> I got following:
> > >>>>
> > >>>> root@mayonaka:~# modprobe snd-sbxfi
> > >>>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t sine
> > >>>>
> > >>>> speaker-test 1.0.15
> > >>>>
> > >>>> Playback device is default
> > >>>> Stream parameters are 96000Hz, S16_LE, 2 channels
> > >>>> Sine wave rate is 440.0000Hz
> > >>>> Rate set to 96000Hz (requested 96000Hz)
> > >>>> [  262.522739] XFi DAC reset timeout
> > >>>>
> > >>>> Period size ran[  262.564029] XFi DAC reset timeout
> > >>>> ge from 32 to 16[  262.620275] XFi DAC reset timeout
> > >>>> 384
> > >>>> Using max b[  262.676529] XFi DAC reset timeout
> > >>>> uffer size 16384[  262.732784] XFi DAC reset timeout
> > >>>>
> > >>>> Periods = 4
> > >>>> w[  262.789038] XFi DAC reset timeout
> > >>>> as set period_size = 4096
> > >>>> was set buffer_size = 16384
> > >>>>  0 - Front Left
> > >>>> [  327.491997] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> > >>>> [  327.492001] Kernel panic - not syncing: softlockup: hung tasks
> > >>>>
> > >>>> and i did hear the sine on the left channel. Hope it helps...
> > >>>>         
> > >>> Try the very latest sound-unstable tree.  Some fixes are there...
> > >>>       
> > >> Without debug i got the same, with debug my box freezed without
> > >> panic, i'l reset it when i get home and will try it again...
> > >>     
> > >
> > > Try the latest version.  Another fix was there.
> > >
> > >
> > > Takashi
> > > _______________________________________________
> > > Alsa-devel mailing list
> > > Alsa-devel@alsa-project.org
> > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > >
> > >   
> > 
> > Tried today's snapshot for my card (X-Fi Fatality Champion Series). No 
> > change.
> 
> Does the patch below already in your snapshot tarball?
> Otherwise it's an older version.

The best way to check whether your snapshot tarball is the latest one
is to see alsa-driver*/HEAD and alsa-driver*/alsa-kernel/HEAD files.
The former corresponds to alsa-driver-build-unstable.git tree, and
the latter to sound-unstable-2.6.git tree.  On web, you can check via
the following URLs:
    http://git.kernel.org/?p=linux/kernel/git/tiwai/alsa-driver-build-unstable.git;a=summary
    http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-unstable-2.6.git;a=summary
Click the top commit entry and compare the commit id there and one in
your HEAD file in the snapshot tarball.

For example, the latest snapshot I uploaded now has alsa-kernel/HEAD:
    a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge branch 'topic/sbxfi'


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Mon, 13 Oct 2008 17:43:03 +0200,
I wrote:
> 
> For example, the latest snapshot I uploaded now has alsa-kernel/HEAD:
>     a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge branch 'topic/sbxfi'

... and again updated to:
  5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch 'topic/sbxfi'


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Mon, 13 Oct 2008 18:02:08 +0200,
I wrote:
> 
> At Mon, 13 Oct 2008 17:43:03 +0200,
> I wrote:
> > 
> > For example, the latest snapshot I uploaded now has alsa-kernel/HEAD:
> >     a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge branch 'topic/sbxfi'
> 
> ... and again updated to:
>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch 'topic/sbxfi'

So, guys, please check the latest one.

If the hang up still occurs with this version, then try to define
XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
With this build option, the driver will use the system timer instead
of emu20k1 timer irqs.

If this still doesn't help, try to remove all spinlocks.  That is,
just comment out all spin_lock*() and spin_unlock*() calls to avoid
spin deadlocks.  Of course, it can be racy, but better than a spin
deadlock.


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

On Mon, 13 Oct 2008 18:05:49 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 13 Oct 2008 18:02:08 +0200,
> I wrote:
> > 
> > At Mon, 13 Oct 2008 17:43:03 +0200,
> > I wrote:
> > > 
> > > For example, the latest snapshot I uploaded now has
> > > alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
> > > branch 'topic/sbxfi'
> > 
> > ... and again updated to:
> >   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
> > 'topic/sbxfi'
> 
> So, guys, please check the latest one.
> 
> If the hang up still occurs with this version, then try to define
> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
> With this build option, the driver will use the system timer instead
> of emu20k1 timer irqs.
> 
> If this still doesn't help, try to remove all spinlocks.  That is,
> just comment out all spin_lock*() and spin_unlock*() calls to avoid
> spin deadlocks.  Of course, it can be racy, but better than a spin
> deadlock.

Now it doesn't hangs :) but speakers-test produces crackling sine and
fails on test...

root@mayonaka:~# speaker-test -c 2 -r 96000 -t
sine                                                                                                            

speaker-test 1.0.15

Playback device is default
Stream parameters are 96000Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 96000Hz (requested 96000Hz)
Buffer size range from 32 to 16384
Period size range from 32 to 16384
Using max buffer size 16384
Periods = 4
was set period_size = 4096
was set buffer_size = 16384
 0 - Front Left
Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Operation not permitted

Also i tried mplayer, 96khz works almost fine (very rare cracklings),
48khz plays slow (like playing 96khz sample on 48khz rate without
resampling), 44.1khz doesn't work at all (mplayer doesn't even
show that it plays).

Master control on mixer seems to be working fine.

-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Alexey Bazhin пишет:
> On Mon, 13 Oct 2008 18:05:49 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
>
>   
>> At Mon, 13 Oct 2008 18:02:08 +0200,
>> I wrote:
>>     
>>> At Mon, 13 Oct 2008 17:43:03 +0200,
>>> I wrote:
>>>       
>>>> For example, the latest snapshot I uploaded now has
>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
>>>> branch 'topic/sbxfi'
>>>>         
>>> ... and again updated to:
>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
>>> 'topic/sbxfi'
>>>       
>> So, guys, please check the latest one.
>>
>> If the hang up still occurs with this version, then try to define
>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
>> With this build option, the driver will use the system timer instead
>> of emu20k1 timer irqs.
>>
>> If this still doesn't help, try to remove all spinlocks.  That is,
>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
>> spin deadlocks.  Of course, it can be racy, but better than a spin
>> deadlock.
>>     
>
> Now it doesn't hangs :) but speakers-test produces crackling sine and
> fails on test...
>
> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
> sine                                                                                                            
>
> speaker-test 1.0.15
>
> Playback device is default
> Stream parameters are 96000Hz, S16_LE, 2 channels
> Sine wave rate is 440.0000Hz
> Rate set to 96000Hz (requested 96000Hz)
> Buffer size range from 32 to 16384
> Period size range from 32 to 16384
> Using max buffer size 16384
> Periods = 4
> was set period_size = 4096
> was set buffer_size = 16384
>  0 - Front Left
> Write error: -5,Input/output error
> xrun_recovery failed: -5,Input/output error
> Transfer failed: Operation not permitted
>
> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
> 48khz plays slow (like playing 96khz sample on 48khz rate without
> resampling), 44.1khz doesn't work at all (mplayer doesn't even
> show that it plays).
>
> Master control on mixer seems to be working fine.
>
>   

ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.bz2
Is that the right URL for latest X-Fi snapshots?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 09:17:08 +0400,
The Source wrote:
> 
> Alexey Bazhin пишет:
> > On Mon, 13 Oct 2008 18:05:49 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> >
> >   
> >> At Mon, 13 Oct 2008 18:02:08 +0200,
> >> I wrote:
> >>     
> >>> At Mon, 13 Oct 2008 17:43:03 +0200,
> >>> I wrote:
> >>>       
> >>>> For example, the latest snapshot I uploaded now has
> >>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
> >>>> branch 'topic/sbxfi'
> >>>>         
> >>> ... and again updated to:
> >>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
> >>> 'topic/sbxfi'
> >>>       
> >> So, guys, please check the latest one.
> >>
> >> If the hang up still occurs with this version, then try to define
> >> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
> >> With this build option, the driver will use the system timer instead
> >> of emu20k1 timer irqs.
> >>
> >> If this still doesn't help, try to remove all spinlocks.  That is,
> >> just comment out all spin_lock*() and spin_unlock*() calls to avoid
> >> spin deadlocks.  Of course, it can be racy, but better than a spin
> >> deadlock.
> >>     
> >
> > Now it doesn't hangs :) but speakers-test produces crackling sine and
> > fails on test...
> >
> > root@mayonaka:~# speaker-test -c 2 -r 96000 -t
> > sine                                                                                                            
> >
> > speaker-test 1.0.15
> >
> > Playback device is default
> > Stream parameters are 96000Hz, S16_LE, 2 channels
> > Sine wave rate is 440.0000Hz
> > Rate set to 96000Hz (requested 96000Hz)
> > Buffer size range from 32 to 16384
> > Period size range from 32 to 16384
> > Using max buffer size 16384
> > Periods = 4
> > was set period_size = 4096
> > was set buffer_size = 16384
> >  0 - Front Left
> > Write error: -5,Input/output error
> > xrun_recovery failed: -5,Input/output error
> > Transfer failed: Operation not permitted
> >
> > Also i tried mplayer, 96khz works almost fine (very rare cracklings),
> > 48khz plays slow (like playing 96khz sample on 48khz rate without
> > resampling), 44.1khz doesn't work at all (mplayer doesn't even
> > show that it plays).
> >
> > Master control on mixer seems to be working fine.
> >
> >   
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.bz2
> Is that the right URL for latest X-Fi snapshots?

Yes.  And check HEAD files in the tarball.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Mon, 13 Oct 2008 23:21:47 +0400,
Alexey Bazhin wrote:
> 
> On Mon, 13 Oct 2008 18:05:49 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Mon, 13 Oct 2008 18:02:08 +0200,
> > I wrote:
> > > 
> > > At Mon, 13 Oct 2008 17:43:03 +0200,
> > > I wrote:
> > > > 
> > > > For example, the latest snapshot I uploaded now has
> > > > alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
> > > > branch 'topic/sbxfi'
> > > 
> > > ... and again updated to:
> > >   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
> > > 'topic/sbxfi'
> > 
> > So, guys, please check the latest one.
> > 
> > If the hang up still occurs with this version, then try to define
> > XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
> > With this build option, the driver will use the system timer instead
> > of emu20k1 timer irqs.
> > 
> > If this still doesn't help, try to remove all spinlocks.  That is,
> > just comment out all spin_lock*() and spin_unlock*() calls to avoid
> > spin deadlocks.  Of course, it can be racy, but better than a spin
> > deadlock.
> 
> Now it doesn't hangs :)

Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
needed?  Or, did it work as is?

> but speakers-test produces crackling sine and
> fails on test...

Do you mean it aborts some time later after starting the stream?
Could you show the kernel messages?  The default debug level should
suffice, I guess.  If any, try debug=2.

> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
> sine                                                                                                            
> 
> speaker-test 1.0.15
> 
> Playback device is default
> Stream parameters are 96000Hz, S16_LE, 2 channels
> Sine wave rate is 440.0000Hz
> Rate set to 96000Hz (requested 96000Hz)
> Buffer size range from 32 to 16384
> Period size range from 32 to 16384
> Using max buffer size 16384
> Periods = 4
> was set period_size = 4096
> was set buffer_size = 16384
>  0 - Front Left
> Write error: -5,Input/output error
> xrun_recovery failed: -5,Input/output error
> Transfer failed: Operation not permitted
> 
> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
> 48khz plays slow (like playing 96khz sample on 48khz rate without
> resampling), 44.1khz doesn't work at all (mplayer doesn't even
> show that it plays).

How about the patch below for 48kHz?

Not sure whether 44.1kHz works at all with the current driver code.
I just guessed that the pitch parameter would handle that.  But, maybe
it's not enough...

> Master control on mixer seems to be working fine.

OK.

[BTW, it'd be appreciated if you add my address to Cc (or, To: my
 address and Cc: to ML like other people do), so that I can check your
 post quickly.]


thanks,

Takashi


diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
index 3fde6a9..47ba941 100644
--- a/sound/pci/sbxfi/sbxfi.c
+++ b/sound/pci/sbxfi/sbxfi.c
@@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
 	unsigned int pitch, pitch_ch;
 
 	/* convert to fixed-point 8.24 format */
-	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
+	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
+	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
 
 	for (i = 0; i < 2; i++) {
 		/* write the pitch to param ring of the corresponsing SRC

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Mon, 13 Oct 2008 23:21:47 +0400,
> Alexey Bazhin wrote:
>   
>> On Mon, 13 Oct 2008 18:05:49 +0200
>> Takashi Iwai <tiwai@suse.de> wrote:
>>
>>     
>>> At Mon, 13 Oct 2008 18:02:08 +0200,
>>> I wrote:
>>>       
>>>> At Mon, 13 Oct 2008 17:43:03 +0200,
>>>> I wrote:
>>>>         
>>>>> For example, the latest snapshot I uploaded now has
>>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
>>>>> branch 'topic/sbxfi'
>>>>>           
>>>> ... and again updated to:
>>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
>>>> 'topic/sbxfi'
>>>>         
>>> So, guys, please check the latest one.
>>>
>>> If the hang up still occurs with this version, then try to define
>>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
>>> With this build option, the driver will use the system timer instead
>>> of emu20k1 timer irqs.
>>>
>>> If this still doesn't help, try to remove all spinlocks.  That is,
>>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
>>> spin deadlocks.  Of course, it can be racy, but better than a spin
>>> deadlock.
>>>       
>> Now it doesn't hangs :)
>>     
>
> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> needed?  Or, did it work as is?
>
>   
>> but speakers-test produces crackling sine and
>> fails on test...
>>     
>
> Do you mean it aborts some time later after starting the stream?
> Could you show the kernel messages?  The default debug level should
> suffice, I guess.  If any, try debug=2.
>
>   
>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
>> sine                                                                                                            
>>
>> speaker-test 1.0.15
>>
>> Playback device is default
>> Stream parameters are 96000Hz, S16_LE, 2 channels
>> Sine wave rate is 440.0000Hz
>> Rate set to 96000Hz (requested 96000Hz)
>> Buffer size range from 32 to 16384
>> Period size range from 32 to 16384
>> Using max buffer size 16384
>> Periods = 4
>> was set period_size = 4096
>> was set buffer_size = 16384
>>  0 - Front Left
>> Write error: -5,Input/output error
>> xrun_recovery failed: -5,Input/output error
>> Transfer failed: Operation not permitted
>>
>> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
>> 48khz plays slow (like playing 96khz sample on 48khz rate without
>> resampling), 44.1khz doesn't work at all (mplayer doesn't even
>> show that it plays).
>>     
>
> How about the patch below for 48kHz?
>
> Not sure whether 44.1kHz works at all with the current driver code.
> I just guessed that the pitch parameter would handle that.  But, maybe
> it's not enough...
>
>   
>> Master control on mixer seems to be working fine.
>>     
>
> OK.
>
> [BTW, it'd be appreciated if you add my address to Cc (or, To: my
>  address and Cc: to ML like other people do), so that I can check your
>  post quickly.]
>
>
> thanks,
>
> Takashi
>
>
> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> index 3fde6a9..47ba941 100644
> --- a/sound/pci/sbxfi/sbxfi.c
> +++ b/sound/pci/sbxfi/sbxfi.c
> @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
>  	unsigned int pitch, pitch_ch;
>  
>  	/* convert to fixed-point 8.24 format */
> -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
> +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
> +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
>  
>  	for (i = 0; i < 2; i++) {
>  		/* write the pitch to param ring of the corresponsing SRC
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>   
Ok, I downloaded todays (14th October) snapshot. At least ftp sais the 
file alsa-driver-unstable-snapshot.tar.bz2 is of 14.10.2008.
I extracted it, ran configure, make , make install. No reboot on aplay 
now, but Oops occurs. Tried with sysytem timer (make clean, changed 
#undef XXX_SYSTEM_TIMER to #define XXX_SYSTEM_TIMER in sbxfi.c, 
configure, make, make install). Oops again.
Here's the error message:
Playing foo.wav: Signed 16bit Little Endian, Rate 22050Hz, Mono
BUG: unable to handle NULL pointer dereference at 0000000000000008
IP: <4> Spurious LAPIC timer interrupt on CPU 1
[<ffffffff811410c7>] __list_add+0x1/0x5b
PGD 14c14e067 PUD 14c14f067
PMD 14e576067 PTE 0
Oops: 0000 [1]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 11:23:42 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Mon, 13 Oct 2008 23:21:47 +0400,
> > Alexey Bazhin wrote:
> >   
> >> On Mon, 13 Oct 2008 18:05:49 +0200
> >> Takashi Iwai <tiwai@suse.de> wrote:
> >>
> >>     
> >>> At Mon, 13 Oct 2008 18:02:08 +0200,
> >>> I wrote:
> >>>       
> >>>> At Mon, 13 Oct 2008 17:43:03 +0200,
> >>>> I wrote:
> >>>>         
> >>>>> For example, the latest snapshot I uploaded now has
> >>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
> >>>>> branch 'topic/sbxfi'
> >>>>>           
> >>>> ... and again updated to:
> >>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
> >>>> 'topic/sbxfi'
> >>>>         
> >>> So, guys, please check the latest one.
> >>>
> >>> If the hang up still occurs with this version, then try to define
> >>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
> >>> With this build option, the driver will use the system timer instead
> >>> of emu20k1 timer irqs.
> >>>
> >>> If this still doesn't help, try to remove all spinlocks.  That is,
> >>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
> >>> spin deadlocks.  Of course, it can be racy, but better than a spin
> >>> deadlock.
> >>>       
> >> Now it doesn't hangs :)
> >>     
> >
> > Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> > needed?  Or, did it work as is?
> >
> >   
> >> but speakers-test produces crackling sine and
> >> fails on test...
> >>     
> >
> > Do you mean it aborts some time later after starting the stream?
> > Could you show the kernel messages?  The default debug level should
> > suffice, I guess.  If any, try debug=2.
> >
> >   
> >> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
> >> sine                                                                                                            
> >>
> >> speaker-test 1.0.15
> >>
> >> Playback device is default
> >> Stream parameters are 96000Hz, S16_LE, 2 channels
> >> Sine wave rate is 440.0000Hz
> >> Rate set to 96000Hz (requested 96000Hz)
> >> Buffer size range from 32 to 16384
> >> Period size range from 32 to 16384
> >> Using max buffer size 16384
> >> Periods = 4
> >> was set period_size = 4096
> >> was set buffer_size = 16384
> >>  0 - Front Left
> >> Write error: -5,Input/output error
> >> xrun_recovery failed: -5,Input/output error
> >> Transfer failed: Operation not permitted
> >>
> >> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
> >> 48khz plays slow (like playing 96khz sample on 48khz rate without
> >> resampling), 44.1khz doesn't work at all (mplayer doesn't even
> >> show that it plays).
> >>     
> >
> > How about the patch below for 48kHz?
> >
> > Not sure whether 44.1kHz works at all with the current driver code.
> > I just guessed that the pitch parameter would handle that.  But, maybe
> > it's not enough...
> >
> >   
> >> Master control on mixer seems to be working fine.
> >>     
> >
> > OK.
> >
> > [BTW, it'd be appreciated if you add my address to Cc (or, To: my
> >  address and Cc: to ML like other people do), so that I can check your
> >  post quickly.]
> >
> >
> > thanks,
> >
> > Takashi
> >
> >
> > diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > index 3fde6a9..47ba941 100644
> > --- a/sound/pci/sbxfi/sbxfi.c
> > +++ b/sound/pci/sbxfi/sbxfi.c
> > @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
> >  	unsigned int pitch, pitch_ch;
> >  
> >  	/* convert to fixed-point 8.24 format */
> > -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
> > +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
> > +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
> >  
> >  	for (i = 0; i < 2; i++) {
> >  		/* write the pitch to param ring of the corresponsing SRC
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> >   
> Ok, I downloaded todays (14th October) snapshot. At least ftp sais the 
> file alsa-driver-unstable-snapshot.tar.bz2 is of 14.10.2008.

Check HEAD files to make sure it's the latest one as I posted.

> I extracted it, ran configure, make , make install. No reboot on aplay 
> now, but Oops occurs. Tried with sysytem timer (make clean, changed 
> #undef XXX_SYSTEM_TIMER to #define XXX_SYSTEM_TIMER in sbxfi.c, 
> configure, make, make install). Oops again.
> Here's the error message:
> Playing foo.wav: Signed 16bit Little Endian, Rate 22050Hz, Mono

As I wrote, try 96kHz samples at first.

> BUG: unable to handle NULL pointer dereference at 0000000000000008
> IP: <4> Spurious LAPIC timer interrupt on CPU 1
> [<ffffffff811410c7>] __list_add+0x1/0x5b
> PGD 14c14e067 PUD 14c14f067
> PMD 14e576067 PTE 0
> Oops: 0000 [1]

More log below that point please.  It contains the stack trace.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Tue, 14 Oct 2008 11:23:42 +0400,
> The Source wrote:
>   
>> Takashi Iwai пишет:
>>     
>>> At Mon, 13 Oct 2008 23:21:47 +0400,
>>> Alexey Bazhin wrote:
>>>   
>>>       
>>>> On Mon, 13 Oct 2008 18:05:49 +0200
>>>> Takashi Iwai <tiwai@suse.de> wrote:
>>>>
>>>>     
>>>>         
>>>>> At Mon, 13 Oct 2008 18:02:08 +0200,
>>>>> I wrote:
>>>>>       
>>>>>           
>>>>>> At Mon, 13 Oct 2008 17:43:03 +0200,
>>>>>> I wrote:
>>>>>>         
>>>>>>             
>>>>>>> For example, the latest snapshot I uploaded now has
>>>>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
>>>>>>> branch 'topic/sbxfi'
>>>>>>>           
>>>>>>>               
>>>>>> ... and again updated to:
>>>>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
>>>>>> 'topic/sbxfi'
>>>>>>         
>>>>>>             
>>>>> So, guys, please check the latest one.
>>>>>
>>>>> If the hang up still occurs with this version, then try to define
>>>>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
>>>>> With this build option, the driver will use the system timer instead
>>>>> of emu20k1 timer irqs.
>>>>>
>>>>> If this still doesn't help, try to remove all spinlocks.  That is,
>>>>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
>>>>> spin deadlocks.  Of course, it can be racy, but better than a spin
>>>>> deadlock.
>>>>>       
>>>>>           
>>>> Now it doesn't hangs :)
>>>>     
>>>>         
>>> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
>>> needed?  Or, did it work as is?
>>>
>>>   
>>>       
>>>> but speakers-test produces crackling sine and
>>>> fails on test...
>>>>     
>>>>         
>>> Do you mean it aborts some time later after starting the stream?
>>> Could you show the kernel messages?  The default debug level should
>>> suffice, I guess.  If any, try debug=2.
>>>
>>>   
>>>       
>>>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
>>>> sine                                                                                                            
>>>>
>>>> speaker-test 1.0.15
>>>>
>>>> Playback device is default
>>>> Stream parameters are 96000Hz, S16_LE, 2 channels
>>>> Sine wave rate is 440.0000Hz
>>>> Rate set to 96000Hz (requested 96000Hz)
>>>> Buffer size range from 32 to 16384
>>>> Period size range from 32 to 16384
>>>> Using max buffer size 16384
>>>> Periods = 4
>>>> was set period_size = 4096
>>>> was set buffer_size = 16384
>>>>  0 - Front Left
>>>> Write error: -5,Input/output error
>>>> xrun_recovery failed: -5,Input/output error
>>>> Transfer failed: Operation not permitted
>>>>
>>>> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
>>>> 48khz plays slow (like playing 96khz sample on 48khz rate without
>>>> resampling), 44.1khz doesn't work at all (mplayer doesn't even
>>>> show that it plays).
>>>>     
>>>>         
>>> How about the patch below for 48kHz?
>>>
>>> Not sure whether 44.1kHz works at all with the current driver code.
>>> I just guessed that the pitch parameter would handle that.  But, maybe
>>> it's not enough...
>>>
>>>   
>>>       
>>>> Master control on mixer seems to be working fine.
>>>>     
>>>>         
>>> OK.
>>>
>>> [BTW, it'd be appreciated if you add my address to Cc (or, To: my
>>>  address and Cc: to ML like other people do), so that I can check your
>>>  post quickly.]
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>
>>>
>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
>>> index 3fde6a9..47ba941 100644
>>> --- a/sound/pci/sbxfi/sbxfi.c
>>> +++ b/sound/pci/sbxfi/sbxfi.c
>>> @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
>>>  	unsigned int pitch, pitch_ch;
>>>  
>>>  	/* convert to fixed-point 8.24 format */
>>> -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
>>> +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
>>> +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
>>>  
>>>  	for (i = 0; i < 2; i++) {
>>>  		/* write the pitch to param ring of the corresponsing SRC
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
>>>   
>>>       
>> Ok, I downloaded todays (14th October) snapshot. At least ftp sais the 
>> file alsa-driver-unstable-snapshot.tar.bz2 is of 14.10.2008.
>>     
>
> Check HEAD files to make sure it's the latest one as I posted.
>
>   
>> I extracted it, ran configure, make , make install. No reboot on aplay 
>> now, but Oops occurs. Tried with sysytem timer (make clean, changed 
>> #undef XXX_SYSTEM_TIMER to #define XXX_SYSTEM_TIMER in sbxfi.c, 
>> configure, make, make install). Oops again.
>> Here's the error message:
>> Playing foo.wav: Signed 16bit Little Endian, Rate 22050Hz, Mono
>>     
>
> As I wrote, try 96kHz samples at first.
>
>   
>> BUG: unable to handle NULL pointer dereference at 0000000000000008
>> IP: <4> Spurious LAPIC timer interrupt on CPU 1
>> [<ffffffff811410c7>] __list_add+0x1/0x5b
>> PGD 14c14e067 PUD 14c14f067
>> PMD 14e576067 PTE 0
>> Oops: 0000 [1]
>>     
>
> More log below that point please.  It contains the stack trace.
>
>
> thanks,
>
> Takashi
>
>   
Where can I get more log? I posted here console output, after that 
system hangs completely.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

On Tue, 14 Oct 2008 08:45:20 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 13 Oct 2008 23:21:47 +0400,
> Alexey Bazhin wrote:
> > 
> > Now it doesn't hangs :)
> 
> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> needed?  Or, did it work as is?
No, i didn't used XXX_SYSTEM_TIMER
 
> > but speakers-test produces crackling sine and
> > fails on test...
> 
> Do you mean it aborts some time later after starting the stream?
Yes

> Could you show the kernel messages?  The default debug level should
> suffice, I guess.  If any, try debug=2.

> How about the patch below for 48kHz?

I'll test it later (my test box freezed again...)

-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 11:58:00 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Tue, 14 Oct 2008 11:23:42 +0400,
> > The Source wrote:
> >   
> >> Takashi Iwai пишет:
> >>     
> >>> At Mon, 13 Oct 2008 23:21:47 +0400,
> >>> Alexey Bazhin wrote:
> >>>   
> >>>       
> >>>> On Mon, 13 Oct 2008 18:05:49 +0200
> >>>> Takashi Iwai <tiwai@suse.de> wrote:
> >>>>
> >>>>     
> >>>>         
> >>>>> At Mon, 13 Oct 2008 18:02:08 +0200,
> >>>>> I wrote:
> >>>>>       
> >>>>>           
> >>>>>> At Mon, 13 Oct 2008 17:43:03 +0200,
> >>>>>> I wrote:
> >>>>>>         
> >>>>>>             
> >>>>>>> For example, the latest snapshot I uploaded now has
> >>>>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
> >>>>>>> branch 'topic/sbxfi'
> >>>>>>>           
> >>>>>>>               
> >>>>>> ... and again updated to:
> >>>>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
> >>>>>> 'topic/sbxfi'
> >>>>>>         
> >>>>>>             
> >>>>> So, guys, please check the latest one.
> >>>>>
> >>>>> If the hang up still occurs with this version, then try to define
> >>>>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
> >>>>> With this build option, the driver will use the system timer instead
> >>>>> of emu20k1 timer irqs.
> >>>>>
> >>>>> If this still doesn't help, try to remove all spinlocks.  That is,
> >>>>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
> >>>>> spin deadlocks.  Of course, it can be racy, but better than a spin
> >>>>> deadlock.
> >>>>>       
> >>>>>           
> >>>> Now it doesn't hangs :)
> >>>>     
> >>>>         
> >>> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> >>> needed?  Or, did it work as is?
> >>>
> >>>   
> >>>       
> >>>> but speakers-test produces crackling sine and
> >>>> fails on test...
> >>>>     
> >>>>         
> >>> Do you mean it aborts some time later after starting the stream?
> >>> Could you show the kernel messages?  The default debug level should
> >>> suffice, I guess.  If any, try debug=2.
> >>>
> >>>   
> >>>       
> >>>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
> >>>> sine                                                                                                            
> >>>>
> >>>> speaker-test 1.0.15
> >>>>
> >>>> Playback device is default
> >>>> Stream parameters are 96000Hz, S16_LE, 2 channels
> >>>> Sine wave rate is 440.0000Hz
> >>>> Rate set to 96000Hz (requested 96000Hz)
> >>>> Buffer size range from 32 to 16384
> >>>> Period size range from 32 to 16384
> >>>> Using max buffer size 16384
> >>>> Periods = 4
> >>>> was set period_size = 4096
> >>>> was set buffer_size = 16384
> >>>>  0 - Front Left
> >>>> Write error: -5,Input/output error
> >>>> xrun_recovery failed: -5,Input/output error
> >>>> Transfer failed: Operation not permitted
> >>>>
> >>>> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
> >>>> 48khz plays slow (like playing 96khz sample on 48khz rate without
> >>>> resampling), 44.1khz doesn't work at all (mplayer doesn't even
> >>>> show that it plays).
> >>>>     
> >>>>         
> >>> How about the patch below for 48kHz?
> >>>
> >>> Not sure whether 44.1kHz works at all with the current driver code.
> >>> I just guessed that the pitch parameter would handle that.  But, maybe
> >>> it's not enough...
> >>>
> >>>   
> >>>       
> >>>> Master control on mixer seems to be working fine.
> >>>>     
> >>>>         
> >>> OK.
> >>>
> >>> [BTW, it'd be appreciated if you add my address to Cc (or, To: my
> >>>  address and Cc: to ML like other people do), so that I can check your
> >>>  post quickly.]
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>>
> >>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> >>> index 3fde6a9..47ba941 100644
> >>> --- a/sound/pci/sbxfi/sbxfi.c
> >>> +++ b/sound/pci/sbxfi/sbxfi.c
> >>> @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
> >>>  	unsigned int pitch, pitch_ch;
> >>>  
> >>>  	/* convert to fixed-point 8.24 format */
> >>> -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
> >>> +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
> >>> +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
> >>>  
> >>>  	for (i = 0; i < 2; i++) {
> >>>  		/* write the pitch to param ring of the corresponsing SRC
> >>> _______________________________________________
> >>> Alsa-devel mailing list
> >>> Alsa-devel@alsa-project.org
> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>>
> >>>   
> >>>       
> >> Ok, I downloaded todays (14th October) snapshot. At least ftp sais the 
> >> file alsa-driver-unstable-snapshot.tar.bz2 is of 14.10.2008.
> >>     
> >
> > Check HEAD files to make sure it's the latest one as I posted.
> >
> >   
> >> I extracted it, ran configure, make , make install. No reboot on aplay 
> >> now, but Oops occurs. Tried with sysytem timer (make clean, changed 
> >> #undef XXX_SYSTEM_TIMER to #define XXX_SYSTEM_TIMER in sbxfi.c, 
> >> configure, make, make install). Oops again.
> >> Here's the error message:
> >> Playing foo.wav: Signed 16bit Little Endian, Rate 22050Hz, Mono
> >>     
> >
> > As I wrote, try 96kHz samples at first.
> >
> >   
> >> BUG: unable to handle NULL pointer dereference at 0000000000000008
> >> IP: <4> Spurious LAPIC timer interrupt on CPU 1
> >> [<ffffffff811410c7>] __list_add+0x1/0x5b
> >> PGD 14c14e067 PUD 14c14f067
> >> PMD 14e576067 PTE 0
> >> Oops: 0000 [1]
> >>     
> >
> > More log below that point please.  It contains the stack trace.
> >
> >
> > thanks,
> >
> > Takashi
> >
> >   
> Where can I get more log? I posted here console output, after that 
> system hangs completely.

That's bad.  Usually you have more logs when you run dmesg.
Does this happen after the fresh reboot, too, right?

[BTW, please post to my address and add Cc to ML instead of posting
 only to ML.  Most developer MLs (like LKML) prefer it.]

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Mon, 13 Oct 2008 23:21:47 +0400,
> Alexey Bazhin wrote:
>   
>> On Mon, 13 Oct 2008 18:05:49 +0200
>> Takashi Iwai <tiwai@suse.de> wrote:
>>
>>     
>>> At Mon, 13 Oct 2008 18:02:08 +0200,
>>> I wrote:
>>>       
>>>> At Mon, 13 Oct 2008 17:43:03 +0200,
>>>> I wrote:
>>>>         
>>>>> For example, the latest snapshot I uploaded now has
>>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
>>>>> branch 'topic/sbxfi'
>>>>>           
>>>> ... and again updated to:
>>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
>>>> 'topic/sbxfi'
>>>>         
>>> So, guys, please check the latest one.
>>>
>>> If the hang up still occurs with this version, then try to define
>>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
>>> With this build option, the driver will use the system timer instead
>>> of emu20k1 timer irqs.
>>>
>>> If this still doesn't help, try to remove all spinlocks.  That is,
>>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
>>> spin deadlocks.  Of course, it can be racy, but better than a spin
>>> deadlock.
>>>       
>> Now it doesn't hangs :)
>>     
>
> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> needed?  Or, did it work as is?
>
>   
>> but speakers-test produces crackling sine and
>> fails on test...
>>     
>
> Do you mean it aborts some time later after starting the stream?
> Could you show the kernel messages?  The default debug level should
> suffice, I guess.  If any, try debug=2.
>
>   
>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
>> sine                                                                                                            
>>
>> speaker-test 1.0.15
>>
>> Playback device is default
>> Stream parameters are 96000Hz, S16_LE, 2 channels
>> Sine wave rate is 440.0000Hz
>> Rate set to 96000Hz (requested 96000Hz)
>> Buffer size range from 32 to 16384
>> Period size range from 32 to 16384
>> Using max buffer size 16384
>> Periods = 4
>> was set period_size = 4096
>> was set buffer_size = 16384
>>  0 - Front Left
>> Write error: -5,Input/output error
>> xrun_recovery failed: -5,Input/output error
>> Transfer failed: Operation not permitted
>>
>> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
>> 48khz plays slow (like playing 96khz sample on 48khz rate without
>> resampling), 44.1khz doesn't work at all (mplayer doesn't even
>> show that it plays).
>>     
>
> How about the patch below for 48kHz?
>
> Not sure whether 44.1kHz works at all with the current driver code.
> I just guessed that the pitch parameter would handle that.  But, maybe
> it's not enough...
>
>   
>> Master control on mixer seems to be working fine.
>>     
>
> OK.
>
> [BTW, it'd be appreciated if you add my address to Cc (or, To: my
>  address and Cc: to ML like other people do), so that I can check your
>  post quickly.]
>
>
> thanks,
>
> Takashi
>
>
> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> index 3fde6a9..47ba941 100644
> --- a/sound/pci/sbxfi/sbxfi.c
> +++ b/sound/pci/sbxfi/sbxfi.c
> @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
>  	unsigned int pitch, pitch_ch;
>  
>  	/* convert to fixed-point 8.24 format */
> -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
> +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
> +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
>  
>  	for (i = 0; i < 2; i++) {
>  		/* write the pitch to param ring of the corresponsing SRC
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>   

Tried 96KHz sample (24bit, Little Endian, 96000Hz, Stereo). No crash, 
hang, reboot. oops, panic etc. But no sound too.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Tue, 14 Oct 2008 12:48:31 +0400,
> The Source wrote:
>   
>> Takashi Iwai пишет:
>>     
>>> At Mon, 13 Oct 2008 23:21:47 +0400,
>>> Alexey Bazhin wrote:
>>>   
>>>       
>>>> On Mon, 13 Oct 2008 18:05:49 +0200
>>>> Takashi Iwai <tiwai@suse.de> wrote:
>>>>
>>>>     
>>>>         
>>>>> At Mon, 13 Oct 2008 18:02:08 +0200,
>>>>> I wrote:
>>>>>       
>>>>>           
>>>>>> At Mon, 13 Oct 2008 17:43:03 +0200,
>>>>>> I wrote:
>>>>>>         
>>>>>>             
>>>>>>> For example, the latest snapshot I uploaded now has
>>>>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
>>>>>>> branch 'topic/sbxfi'
>>>>>>>           
>>>>>>>               
>>>>>> ... and again updated to:
>>>>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
>>>>>> 'topic/sbxfi'
>>>>>>         
>>>>>>             
>>>>> So, guys, please check the latest one.
>>>>>
>>>>> If the hang up still occurs with this version, then try to define
>>>>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
>>>>> With this build option, the driver will use the system timer instead
>>>>> of emu20k1 timer irqs.
>>>>>
>>>>> If this still doesn't help, try to remove all spinlocks.  That is,
>>>>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
>>>>> spin deadlocks.  Of course, it can be racy, but better than a spin
>>>>> deadlock.
>>>>>       
>>>>>           
>>>> Now it doesn't hangs :)
>>>>     
>>>>         
>>> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
>>> needed?  Or, did it work as is?
>>>
>>>   
>>>       
>>>> but speakers-test produces crackling sine and
>>>> fails on test...
>>>>     
>>>>         
>>> Do you mean it aborts some time later after starting the stream?
>>> Could you show the kernel messages?  The default debug level should
>>> suffice, I guess.  If any, try debug=2.
>>>
>>>   
>>>       
>>>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
>>>> sine                                                                                                            
>>>>
>>>> speaker-test 1.0.15
>>>>
>>>> Playback device is default
>>>> Stream parameters are 96000Hz, S16_LE, 2 channels
>>>> Sine wave rate is 440.0000Hz
>>>> Rate set to 96000Hz (requested 96000Hz)
>>>> Buffer size range from 32 to 16384
>>>> Period size range from 32 to 16384
>>>> Using max buffer size 16384
>>>> Periods = 4
>>>> was set period_size = 4096
>>>> was set buffer_size = 16384
>>>>  0 - Front Left
>>>> Write error: -5,Input/output error
>>>> xrun_recovery failed: -5,Input/output error
>>>> Transfer failed: Operation not permitted
>>>>
>>>> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
>>>> 48khz plays slow (like playing 96khz sample on 48khz rate without
>>>> resampling), 44.1khz doesn't work at all (mplayer doesn't even
>>>> show that it plays).
>>>>     
>>>>         
>>> How about the patch below for 48kHz?
>>>
>>> Not sure whether 44.1kHz works at all with the current driver code.
>>> I just guessed that the pitch parameter would handle that.  But, maybe
>>> it's not enough...
>>>
>>>   
>>>       
>>>> Master control on mixer seems to be working fine.
>>>>     
>>>>         
>>> OK.
>>>
>>> [BTW, it'd be appreciated if you add my address to Cc (or, To: my
>>>  address and Cc: to ML like other people do), so that I can check your
>>>  post quickly.]
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>
>>>
>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
>>> index 3fde6a9..47ba941 100644
>>> --- a/sound/pci/sbxfi/sbxfi.c
>>> +++ b/sound/pci/sbxfi/sbxfi.c
>>> @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
>>>  	unsigned int pitch, pitch_ch;
>>>  
>>>  	/* convert to fixed-point 8.24 format */
>>> -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
>>> +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
>>> +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
>>>  
>>>  	for (i = 0; i < 2; i++) {
>>>  		/* write the pitch to param ring of the corresponsing SRC
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
>>>   
>>>       
>> Tried 96KHz sample (24bit, Little Endian, 96000Hz, Stereo). No crash, 
>> hang, reboot. oops, panic etc. But no sound too.
>>     
>
> Strange.  Oops shouldn't depend on the rate, at least...
>
> Did you raise the master volume?
>
>
> Takashi
>
>   
Yes, to 100%
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 12:48:31 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Mon, 13 Oct 2008 23:21:47 +0400,
> > Alexey Bazhin wrote:
> >   
> >> On Mon, 13 Oct 2008 18:05:49 +0200
> >> Takashi Iwai <tiwai@suse.de> wrote:
> >>
> >>     
> >>> At Mon, 13 Oct 2008 18:02:08 +0200,
> >>> I wrote:
> >>>       
> >>>> At Mon, 13 Oct 2008 17:43:03 +0200,
> >>>> I wrote:
> >>>>         
> >>>>> For example, the latest snapshot I uploaded now has
> >>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
> >>>>> branch 'topic/sbxfi'
> >>>>>           
> >>>> ... and again updated to:
> >>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
> >>>> 'topic/sbxfi'
> >>>>         
> >>> So, guys, please check the latest one.
> >>>
> >>> If the hang up still occurs with this version, then try to define
> >>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
> >>> With this build option, the driver will use the system timer instead
> >>> of emu20k1 timer irqs.
> >>>
> >>> If this still doesn't help, try to remove all spinlocks.  That is,
> >>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
> >>> spin deadlocks.  Of course, it can be racy, but better than a spin
> >>> deadlock.
> >>>       
> >> Now it doesn't hangs :)
> >>     
> >
> > Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> > needed?  Or, did it work as is?
> >
> >   
> >> but speakers-test produces crackling sine and
> >> fails on test...
> >>     
> >
> > Do you mean it aborts some time later after starting the stream?
> > Could you show the kernel messages?  The default debug level should
> > suffice, I guess.  If any, try debug=2.
> >
> >   
> >> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
> >> sine                                                                                                            
> >>
> >> speaker-test 1.0.15
> >>
> >> Playback device is default
> >> Stream parameters are 96000Hz, S16_LE, 2 channels
> >> Sine wave rate is 440.0000Hz
> >> Rate set to 96000Hz (requested 96000Hz)
> >> Buffer size range from 32 to 16384
> >> Period size range from 32 to 16384
> >> Using max buffer size 16384
> >> Periods = 4
> >> was set period_size = 4096
> >> was set buffer_size = 16384
> >>  0 - Front Left
> >> Write error: -5,Input/output error
> >> xrun_recovery failed: -5,Input/output error
> >> Transfer failed: Operation not permitted
> >>
> >> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
> >> 48khz plays slow (like playing 96khz sample on 48khz rate without
> >> resampling), 44.1khz doesn't work at all (mplayer doesn't even
> >> show that it plays).
> >>     
> >
> > How about the patch below for 48kHz?
> >
> > Not sure whether 44.1kHz works at all with the current driver code.
> > I just guessed that the pitch parameter would handle that.  But, maybe
> > it's not enough...
> >
> >   
> >> Master control on mixer seems to be working fine.
> >>     
> >
> > OK.
> >
> > [BTW, it'd be appreciated if you add my address to Cc (or, To: my
> >  address and Cc: to ML like other people do), so that I can check your
> >  post quickly.]
> >
> >
> > thanks,
> >
> > Takashi
> >
> >
> > diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > index 3fde6a9..47ba941 100644
> > --- a/sound/pci/sbxfi/sbxfi.c
> > +++ b/sound/pci/sbxfi/sbxfi.c
> > @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
> >  	unsigned int pitch, pitch_ch;
> >  
> >  	/* convert to fixed-point 8.24 format */
> > -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
> > +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
> > +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
> >  
> >  	for (i = 0; i < 2; i++) {
> >  		/* write the pitch to param ring of the corresponsing SRC
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> >   
> 
> Tried 96KHz sample (24bit, Little Endian, 96000Hz, Stereo). No crash, 
> hang, reboot. oops, panic etc. But no sound too.

Strange.  Oops shouldn't depend on the rate, at least...

Did you raise the master volume?


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 12:55:01 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Tue, 14 Oct 2008 12:48:31 +0400,
> > The Source wrote:
> >   
> >> Takashi Iwai пишет:
> >>     
> >>> At Mon, 13 Oct 2008 23:21:47 +0400,
> >>> Alexey Bazhin wrote:
> >>>   
> >>>       
> >>>> On Mon, 13 Oct 2008 18:05:49 +0200
> >>>> Takashi Iwai <tiwai@suse.de> wrote:
> >>>>
> >>>>     
> >>>>         
> >>>>> At Mon, 13 Oct 2008 18:02:08 +0200,
> >>>>> I wrote:
> >>>>>       
> >>>>>           
> >>>>>> At Mon, 13 Oct 2008 17:43:03 +0200,
> >>>>>> I wrote:
> >>>>>>         
> >>>>>>             
> >>>>>>> For example, the latest snapshot I uploaded now has
> >>>>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
> >>>>>>> branch 'topic/sbxfi'
> >>>>>>>           
> >>>>>>>               
> >>>>>> ... and again updated to:
> >>>>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
> >>>>>> 'topic/sbxfi'
> >>>>>>         
> >>>>>>             
> >>>>> So, guys, please check the latest one.
> >>>>>
> >>>>> If the hang up still occurs with this version, then try to define
> >>>>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
> >>>>> With this build option, the driver will use the system timer instead
> >>>>> of emu20k1 timer irqs.
> >>>>>
> >>>>> If this still doesn't help, try to remove all spinlocks.  That is,
> >>>>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
> >>>>> spin deadlocks.  Of course, it can be racy, but better than a spin
> >>>>> deadlock.
> >>>>>       
> >>>>>           
> >>>> Now it doesn't hangs :)
> >>>>     
> >>>>         
> >>> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> >>> needed?  Or, did it work as is?
> >>>
> >>>   
> >>>       
> >>>> but speakers-test produces crackling sine and
> >>>> fails on test...
> >>>>     
> >>>>         
> >>> Do you mean it aborts some time later after starting the stream?
> >>> Could you show the kernel messages?  The default debug level should
> >>> suffice, I guess.  If any, try debug=2.
> >>>
> >>>   
> >>>       
> >>>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
> >>>> sine                                                                                                            
> >>>>
> >>>> speaker-test 1.0.15
> >>>>
> >>>> Playback device is default
> >>>> Stream parameters are 96000Hz, S16_LE, 2 channels
> >>>> Sine wave rate is 440.0000Hz
> >>>> Rate set to 96000Hz (requested 96000Hz)
> >>>> Buffer size range from 32 to 16384
> >>>> Period size range from 32 to 16384
> >>>> Using max buffer size 16384
> >>>> Periods = 4
> >>>> was set period_size = 4096
> >>>> was set buffer_size = 16384
> >>>>  0 - Front Left
> >>>> Write error: -5,Input/output error
> >>>> xrun_recovery failed: -5,Input/output error
> >>>> Transfer failed: Operation not permitted
> >>>>
> >>>> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
> >>>> 48khz plays slow (like playing 96khz sample on 48khz rate without
> >>>> resampling), 44.1khz doesn't work at all (mplayer doesn't even
> >>>> show that it plays).
> >>>>     
> >>>>         
> >>> How about the patch below for 48kHz?
> >>>
> >>> Not sure whether 44.1kHz works at all with the current driver code.
> >>> I just guessed that the pitch parameter would handle that.  But, maybe
> >>> it's not enough...
> >>>
> >>>   
> >>>       
> >>>> Master control on mixer seems to be working fine.
> >>>>     
> >>>>         
> >>> OK.
> >>>
> >>> [BTW, it'd be appreciated if you add my address to Cc (or, To: my
> >>>  address and Cc: to ML like other people do), so that I can check your
> >>>  post quickly.]
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>>
> >>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> >>> index 3fde6a9..47ba941 100644
> >>> --- a/sound/pci/sbxfi/sbxfi.c
> >>> +++ b/sound/pci/sbxfi/sbxfi.c
> >>> @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
> >>>  	unsigned int pitch, pitch_ch;
> >>>  
> >>>  	/* convert to fixed-point 8.24 format */
> >>> -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
> >>> +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
> >>> +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
> >>>  
> >>>  	for (i = 0; i < 2; i++) {
> >>>  		/* write the pitch to param ring of the corresponsing SRC
> >>> _______________________________________________
> >>> Alsa-devel mailing list
> >>> Alsa-devel@alsa-project.org
> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>>
> >>>   
> >>>       
> >> Tried 96KHz sample (24bit, Little Endian, 96000Hz, Stereo). No crash, 
> >> hang, reboot. oops, panic etc. But no sound too.
> >>     
> >
> > Strange.  Oops shouldn't depend on the rate, at least...
> >
> > Did you raise the master volume?
> >
> >
> > Takashi
> >
> >   
> Yes, to 100%

OK, could you then show the kernel messages?
Now the driver must show something useful.

Also, if you load the driver with debug=3 module option, it will log
the whole register accesses.  Note that the whole can be really
long, so do it just only when you want.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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

Takashi Iwai пишет:
> At Mon, 13 Oct 2008 23:21:47 +0400,
> Alexey Bazhin wrote:
>   
>> On Mon, 13 Oct 2008 18:05:49 +0200
>> Takashi Iwai <tiwai@suse.de> wrote:
>>
>>     
>>> At Mon, 13 Oct 2008 18:02:08 +0200,
>>> I wrote:
>>>       
>>>> At Mon, 13 Oct 2008 17:43:03 +0200,
>>>> I wrote:
>>>>         
>>>>> For example, the latest snapshot I uploaded now has
>>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge
>>>>> branch 'topic/sbxfi'
>>>>>           
>>>> ... and again updated to:
>>>>   5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch
>>>> 'topic/sbxfi'
>>>>         
>>> So, guys, please check the latest one.
>>>
>>> If the hang up still occurs with this version, then try to define
>>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.
>>> With this build option, the driver will use the system timer instead
>>> of emu20k1 timer irqs.
>>>
>>> If this still doesn't help, try to remove all spinlocks.  That is,
>>> just comment out all spin_lock*() and spin_unlock*() calls to avoid
>>> spin deadlocks.  Of course, it can be racy, but better than a spin
>>> deadlock.
>>>       
>> Now it doesn't hangs :)
>>     
>
> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> needed?  Or, did it work as is?
>
>   
>> but speakers-test produces crackling sine and
>> fails on test...
>>     
>
> Do you mean it aborts some time later after starting the stream?
> Could you show the kernel messages?  The default debug level should
> suffice, I guess.  If any, try debug=2.
>
>   
>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t
>> sine                                                                                                            
>>
>> speaker-test 1.0.15
>>
>> Playback device is default
>> Stream parameters are 96000Hz, S16_LE, 2 channels
>> Sine wave rate is 440.0000Hz
>> Rate set to 96000Hz (requested 96000Hz)
>> Buffer size range from 32 to 16384
>> Period size range from 32 to 16384
>> Using max buffer size 16384
>> Periods = 4
>> was set period_size = 4096
>> was set buffer_size = 16384
>>  0 - Front Left
>> Write error: -5,Input/output error
>> xrun_recovery failed: -5,Input/output error
>> Transfer failed: Operation not permitted
>>
>> Also i tried mplayer, 96khz works almost fine (very rare cracklings),
>> 48khz plays slow (like playing 96khz sample on 48khz rate without
>> resampling), 44.1khz doesn't work at all (mplayer doesn't even
>> show that it plays).
>>     
>
> How about the patch below for 48kHz?
>
> Not sure whether 44.1kHz works at all with the current driver code.
> I just guessed that the pitch parameter would handle that.  But, maybe
> it's not enough...
>
>   
>> Master control on mixer seems to be working fine.
>>     
>
> OK.
>
> [BTW, it'd be appreciated if you add my address to Cc (or, To: my
>  address and Cc: to ML like other people do), so that I can check your
>  post quickly.]
>
>
> thanks,
>
> Takashi
>
>
> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> index 3fde6a9..47ba941 100644
> --- a/sound/pci/sbxfi/sbxfi.c
> +++ b/sound/pci/sbxfi/sbxfi.c
> @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,
>  	unsigned int pitch, pitch_ch;
>  
>  	/* convert to fixed-point 8.24 format */
> -	pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);
> +	/* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */
> +	pitch = div_u64(runtime->rate * (1ULL << 24), 96000);
>  
>  	for (i = 0; i < 2; i++) {
>  		/* write the pitch to param ring of the corresponsing SRC
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>   
Ok, got the dmesg output with debug=3. Hope that helps.


[-- Attachment #2: dmesg.out.bz2 --]
[-- Type: application/x-bzip, Size: 11093 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 13:17:32 +0400,
The Source wrote:
> 
> Ok, got the dmesg output with debug=3. Hope that helps.

Thanks.  Is it the output with the system timer (XXX_SYSTEM_TIMER)?

I updated the GIT and snapshot tarball again.  It's just some more
additions of debug log points and typo corrections.  Anyway, try to
update.

Regarding your silent output: it seems your device is detected as
SB055x, and it goes to a special DAC initialization unlike others.
Maybe that's the cause.

Does the patch below have any change?


thanks,

Takashi

diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
index 6ae83aa..100b265 100644
--- a/sound/pci/sbxfi/sbxfi.c
+++ b/sound/pci/sbxfi/sbxfi.c
@@ -671,6 +671,7 @@ static void sbxfi_init_dac(struct sbxfi *chip)
 	int i;
 
 	LOG(1, "INIT DAC\n");
+#if 0
 	if (chip->type == SBXFI_HW_055x) {
 		/* XXX what this? */
 		gpio = sbxfi_read(chip, GPIO);
@@ -679,6 +680,7 @@ static void sbxfi_init_dac(struct sbxfi *chip)
 		sbxfi_write(chip, GPIO, gpio);
 		return;
 	}
+#endif
 
 	/* Mute outputs: GPIO6 low */
 	gpio = sbxfi_read(chip, GPIO);

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 12:52:59 +0200,
I wrote:
> 
> At Tue, 14 Oct 2008 13:17:32 +0400,
> The Source wrote:
> > 
> > Ok, got the dmesg output with debug=3. Hope that helps.
> 
> Thanks.  Is it the output with the system timer (XXX_SYSTEM_TIMER)?
> 
> I updated the GIT and snapshot tarball again.  It's just some more
> additions of debug log points and typo corrections.  Anyway, try to
> update.
> 
> Regarding your silent output: it seems your device is detected as
> SB055x, and it goes to a special DAC initialization unlike others.
> Maybe that's the cause.
> 
> Does the patch below have any change?

Argh, apparently this patch won't change anything.  Forget it.
I misread the log.  Seems your hardware is the type ORIG.


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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

Takashi Iwai пишет:
> At Tue, 14 Oct 2008 13:17:32 +0400,
> The Source wrote:
>   
>> Ok, got the dmesg output with debug=3. Hope that helps.
>>     
>
> Thanks.  Is it the output with the system timer (XXX_SYSTEM_TIMER)?
>
> I updated the GIT and snapshot tarball again.  It's just some more
> additions of debug log points and typo corrections.  Anyway, try to
> update.
>
> Regarding your silent output: it seems your device is detected as
> SB055x, and it goes to a special DAC initialization unlike others.
> Maybe that's the cause.
>
> Does the patch below have any change?
>
>
> thanks,
>
> Takashi
>
> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> index 6ae83aa..100b265 100644
> --- a/sound/pci/sbxfi/sbxfi.c
> +++ b/sound/pci/sbxfi/sbxfi.c
> @@ -671,6 +671,7 @@ static void sbxfi_init_dac(struct sbxfi *chip)
>  	int i;
>  
>  	LOG(1, "INIT DAC\n");
> +#if 0
>  	if (chip->type == SBXFI_HW_055x) {
>  		/* XXX what this? */
>  		gpio = sbxfi_read(chip, GPIO);
> @@ -679,6 +680,7 @@ static void sbxfi_init_dac(struct sbxfi *chip)
>  		sbxfi_write(chip, GPIO, gpio);
>  		return;
>  	}
> +#endif
>  
>  	/* Mute outputs: GPIO6 low */
>  	gpio = sbxfi_read(chip, GPIO);
>
>   
Here's dmesg output with the new tarball (system timer is not used this 
time but that doesn't seem to change anything).

By the way, note, that not rate may cause oops but number of channles 
for example (wav that causes oops has mono mode and the one that just 
plays silently - stereo. Also the oops sample is 16bit, silent one is 
24bit).

[-- Attachment #2: dmesg.out.bz2 --]
[-- Type: application/x-bzip, Size: 12522 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Tue, 14 Oct 2008 12:52:59 +0200,
> I wrote:
>   
>> At Tue, 14 Oct 2008 13:17:32 +0400,
>> The Source wrote:
>>     
>>> Ok, got the dmesg output with debug=3. Hope that helps.
>>>       
>> Thanks.  Is it the output with the system timer (XXX_SYSTEM_TIMER)?
>>
>> I updated the GIT and snapshot tarball again.  It's just some more
>> additions of debug log points and typo corrections.  Anyway, try to
>> update.
>>
>> Regarding your silent output: it seems your device is detected as
>> SB055x, and it goes to a special DAC initialization unlike others.
>> Maybe that's the cause.
>>
>> Does the patch below have any change?
>>     
>
> Argh, apparently this patch won't change anything.  Forget it.
> I misread the log.  Seems your hardware is the type ORIG.
>
>
> Takashi
>
>   
A small question: can my card (Platinum Fatality Champion Series) work 
in intel hda mode?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 18:11:33 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Tue, 14 Oct 2008 12:52:59 +0200,
> > I wrote:
> >   
> >> At Tue, 14 Oct 2008 13:17:32 +0400,
> >> The Source wrote:
> >>     
> >>> Ok, got the dmesg output with debug=3. Hope that helps.
> >>>       
> >> Thanks.  Is it the output with the system timer (XXX_SYSTEM_TIMER)?
> >>
> >> I updated the GIT and snapshot tarball again.  It's just some more
> >> additions of debug log points and typo corrections.  Anyway, try to
> >> update.
> >>
> >> Regarding your silent output: it seems your device is detected as
> >> SB055x, and it goes to a special DAC initialization unlike others.
> >> Maybe that's the cause.
> >>
> >> Does the patch below have any change?
> >>     
> >
> > Argh, apparently this patch won't change anything.  Forget it.
> > I misread the log.  Seems your hardware is the type ORIG.
> >
> >
> > Takashi
> >
> >   
> A small question: can my card (Platinum Fatality Champion Series) work 
> in intel hda mode?

I guess no.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Vedran Miletić]

Let's clear this up right here: are only cards which can work in UAA
(snd-hda-intel) mode ones that have _two_ chipsets on board, where
second one is CA0112 or CA0110? Is that needed just for 20k1? Do 20k2
models have that feature builtin?

2008/10/14 Takashi Iwai <tiwai@suse.de>:
> At Tue, 14 Oct 2008 18:11:33 +0400,
> The Source wrote:
>>
>> Takashi Iwai пишет:
>> > At Tue, 14 Oct 2008 12:52:59 +0200,
>> > I wrote:
>> >
>> >> At Tue, 14 Oct 2008 13:17:32 +0400,
>> >> The Source wrote:
>> >>
>> >>> Ok, got the dmesg output with debug=3. Hope that helps.
>> >>>
>> >> Thanks.  Is it the output with the system timer (XXX_SYSTEM_TIMER)?
>> >>
>> >> I updated the GIT and snapshot tarball again.  It's just some more
>> >> additions of debug log points and typo corrections.  Anyway, try to
>> >> update.
>> >>
>> >> Regarding your silent output: it seems your device is detected as
>> >> SB055x, and it goes to a special DAC initialization unlike others.
>> >> Maybe that's the cause.
>> >>
>> >> Does the patch below have any change?
>> >>
>> >
>> > Argh, apparently this patch won't change anything.  Forget it.
>> > I misread the log.  Seems your hardware is the type ORIG.
>> >
>> >
>> > Takashi
>> >
>> >
>> A small question: can my card (Platinum Fatality Champion Series) work
>> in intel hda mode?
>
> I guess no.
>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>



-- 
Vedran Miletić
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 18:22:42 +0200,
=?UTF-8?Q?Vedran_Mileti=C4=87?= wrote:
> 
> Let's clear this up right here: are only cards which can work in UAA
> (snd-hda-intel) mode ones that have _two_ chipsets on board, where
> second one is CA0112 or CA0110? Is that needed just for 20k1? Do 20k2
> models have that feature builtin?

You can check the PCI IDs.  If it appears as 1102:0009 or 1102:000b,
it's HD-audio.  Or check whether any device with class 0403, not
0401.


Takashi

> 2008/10/14 Takashi Iwai <tiwai@suse.de>:
> > At Tue, 14 Oct 2008 18:11:33 +0400,
> > The Source wrote:
> >>
> >> Takashi Iwai пишет:
> >> > At Tue, 14 Oct 2008 12:52:59 +0200,
> >> > I wrote:
> >> >
> >> >> At Tue, 14 Oct 2008 13:17:32 +0400,
> >> >> The Source wrote:
> >> >>
> >> >>> Ok, got the dmesg output with debug=3. Hope that helps.
> >> >>>
> >> >> Thanks.  Is it the output with the system timer (XXX_SYSTEM_TIMER)?
> >> >>
> >> >> I updated the GIT and snapshot tarball again.  It's just some more
> >> >> additions of debug log points and typo corrections.  Anyway, try to
> >> >> update.
> >> >>
> >> >> Regarding your silent output: it seems your device is detected as
> >> >> SB055x, and it goes to a special DAC initialization unlike others.
> >> >> Maybe that's the cause.
> >> >>
> >> >> Does the patch below have any change?
> >> >>
> >> >
> >> > Argh, apparently this patch won't change anything.  Forget it.
> >> > I misread the log.  Seems your hardware is the type ORIG.
> >> >
> >> >
> >> > Takashi
> >> >
> >> >
> >> A small question: can my card (Platinum Fatality Champion Series) work
> >> in intel hda mode?
> >
> > I guess no.
> >
> >
> > Takashi
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> 
> 
> 
> -- 
> Vedran Miletić
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

On Tue, 14 Oct 2008 08:45:20 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Mon, 13 Oct 2008 23:21:47 +0400,
> Alexey Bazhin wrote:
> > 
> > Now it doesn't hangs :)
> 
> Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> needed?  Or, did it work as is?
> 
> > but speakers-test produces crackling sine and
> > fails on test...
> 
> Do you mean it aborts some time later after starting the stream?
> Could you show the kernel messages?  The default debug level should
> suffice, I guess.  If any, try debug=2.

root@mayonaka:~/linux-2.6# dmesg -c >/dev/null
root@mayonaka:~/linux-2.6# insmod sound/pci/sbxfi/snd-sbxfi.ko
root@mayonaka:~/linux-2.6# dmesg
[ 2957.493602] SBXFI: INIT HW
[ 2957.596133] SBXFI: Setting TLB buffer page 0xc02000
root@mayonaka:~/linux-2.6# speaker-test -c 2 -r 96000 -t sine

speaker-test 1.0.15

Playback device is default
Stream parameters are 96000Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 96000Hz (requested 96000Hz)
Buffer size range from 32 to 16384
Period size range from 32 to 16384
Using max buffer size 16384
Periods = 4
was set period_size = 4096
was set buffer_size = 16384
 0 - Front Left



Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Operation not permitted
root@mayonaka:~/linux-2.6# 
root@mayonaka:~/linux-2.6# dmesg
[ 2957.493602] SBXFI: INIT HW
[ 2957.596133] SBXFI: Setting TLB buffer page 0xc02000
[ 2974.854578] SBXFI: Allocate SRC 0
[ 2974.855368] SBXFI: allocated TLB at 0 for 16 pages
[ 2974.855372] SBXFI: filled TLB pages starting at 0xc10000
[ 2974.855393] SBXFI: PLAYBACK PREPARE: rate=96000, period_size=4096,
buffer_size=16384
[ 2974.855396] SBXFI: INIT DAC
[ 2974.855400] SBXFI: RESET DAC
[ 2975.059435] SBXFI: SETUP I2S
[ 2975.059445] SBXFI: Pitch [0:fa6] = 0x1000000
[ 2975.059449] SBXFI: Pitch [80:7a6] = 0x1000000
[ 2975.059453] SBXFI: Pitch [1:fb6] = 0x1000000
[ 2975.059456] SBXFI: Pitch [81:7b6] = 0x1000000
[ 2975.059460] SBXFI: Amp [00:0001] = 0x101c
[ 2975.059465] SBXFI: Amp [80:07a6] = 0x101c
[ 2975.059470] SBXFI: Amp [01:0011] = 0x101c
[ 2975.059474] SBXFI: Amp [81:07b6] = 0x101c
[ 2975.062594] SBXFI: PLAY TRIGGER START
[ 2975.062600] SBXFI: SETUP SRC: ch=0x0, start=0x0, loop=0x10000,
cache=0x100, ctrl=0x1045c 
[ 2975.062612] SBXFI: SETUP SRC: ch=0x1, start=0x0, loop=0x10000,
cache=0x100, ctrl=0x5c
[ 2975.062625] SBXFI: PLAY UPDATE TIMER
[ 2995.148059] SBXFI: PLAY TRIGGER STOP
[ 2995.148072] SBXFI: PLAY UPDATE TIMER
[ 2995.148079] SBXFI: release TLB at 0 for 16 pages
[ 2995.148218] SBXFI: Release SRC 0

Two more things:
-speakers-test on 48khz doesn't produce above errors, but frequency is
still not right
-24-bit samples is silent for me too

> How about the patch below for 48kHz?
Didn't changed anything...

-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 15 Oct 2008 00:35:31 +0400,
Alexey Bazhin wrote:
> 
> On Tue, 14 Oct 2008 08:45:20 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Mon, 13 Oct 2008 23:21:47 +0400,
> > Alexey Bazhin wrote:
> > > 
> > > Now it doesn't hangs :)
> > 
> > Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any workaround
> > needed?  Or, did it work as is?
> > 
> > > but speakers-test produces crackling sine and
> > > fails on test...
> > 
> > Do you mean it aborts some time later after starting the stream?
> > Could you show the kernel messages?  The default debug level should
> > suffice, I guess.  If any, try debug=2.
> 
> root@mayonaka:~/linux-2.6# dmesg -c >/dev/null
> root@mayonaka:~/linux-2.6# insmod sound/pci/sbxfi/snd-sbxfi.ko
> root@mayonaka:~/linux-2.6# dmesg
> [ 2957.493602] SBXFI: INIT HW
> [ 2957.596133] SBXFI: Setting TLB buffer page 0xc02000
> root@mayonaka:~/linux-2.6# speaker-test -c 2 -r 96000 -t sine
> 
> speaker-test 1.0.15
> 
> Playback device is default
> Stream parameters are 96000Hz, S16_LE, 2 channels
> Sine wave rate is 440.0000Hz
> Rate set to 96000Hz (requested 96000Hz)
> Buffer size range from 32 to 16384
> Period size range from 32 to 16384
> Using max buffer size 16384
> Periods = 4
> was set period_size = 4096
> was set buffer_size = 16384
>  0 - Front Left
> 
> 
> 
> Write error: -5,Input/output error
> xrun_recovery failed: -5,Input/output error
> Transfer failed: Operation not permitted
> root@mayonaka:~/linux-2.6# 
> root@mayonaka:~/linux-2.6# dmesg
> [ 2957.493602] SBXFI: INIT HW
> [ 2957.596133] SBXFI: Setting TLB buffer page 0xc02000
> [ 2974.854578] SBXFI: Allocate SRC 0
> [ 2974.855368] SBXFI: allocated TLB at 0 for 16 pages
> [ 2974.855372] SBXFI: filled TLB pages starting at 0xc10000
> [ 2974.855393] SBXFI: PLAYBACK PREPARE: rate=96000, period_size=4096,
> buffer_size=16384
> [ 2974.855396] SBXFI: INIT DAC
> [ 2974.855400] SBXFI: RESET DAC
> [ 2975.059435] SBXFI: SETUP I2S
> [ 2975.059445] SBXFI: Pitch [0:fa6] = 0x1000000
> [ 2975.059449] SBXFI: Pitch [80:7a6] = 0x1000000
> [ 2975.059453] SBXFI: Pitch [1:fb6] = 0x1000000
> [ 2975.059456] SBXFI: Pitch [81:7b6] = 0x1000000
> [ 2975.059460] SBXFI: Amp [00:0001] = 0x101c
> [ 2975.059465] SBXFI: Amp [80:07a6] = 0x101c
> [ 2975.059470] SBXFI: Amp [01:0011] = 0x101c
> [ 2975.059474] SBXFI: Amp [81:07b6] = 0x101c
> [ 2975.062594] SBXFI: PLAY TRIGGER START
> [ 2975.062600] SBXFI: SETUP SRC: ch=0x0, start=0x0, loop=0x10000,
> cache=0x100, ctrl=0x1045c 
> [ 2975.062612] SBXFI: SETUP SRC: ch=0x1, start=0x0, loop=0x10000,
> cache=0x100, ctrl=0x5c
> [ 2975.062625] SBXFI: PLAY UPDATE TIMER
> [ 2995.148059] SBXFI: PLAY TRIGGER STOP
> [ 2995.148072] SBXFI: PLAY UPDATE TIMER
> [ 2995.148079] SBXFI: release TLB at 0 for 16 pages
> [ 2995.148218] SBXFI: Release SRC 0

Hmm, then there is no serious error here.  Did you build the driver
with --with-debug=full or --with-debug=detect option?
Also, run with debug=2.  Then it prints the timer/IRQ handling, too.

Does this happen with aplay, too?

Also, please track via strace to check which syscall it gets an error.

> Two more things:
> -speakers-test on 48khz doesn't produce above errors, but frequency is
> still not right

OK, let's postpone this issue.

> -24-bit samples is silent for me too

Too?  What are other cases that cause silent output?

Also, can you check whether "aplay -M foo.wav" (with 96khz sound file)
gives any output?

> > How about the patch below for 48kHz?
> Didn't changed anything...

OK.  Just to make clear: you get any (more or less) reasonable sound,
not silent, with 96kHz stereo, right?
If yes, then there seems a difference between machines or
environments.  Could you clarify your system again?


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 15:24:22 +0400,
The Source wrote:
> 
> By the way, note, that not rate may cause oops but number of channles 
> for example (wav that causes oops has mono mode and the one that just 
> plays silently - stereo. Also the oops sample is 16bit, silent one is 
> 24bit).

This is an important information.  The driver basically supports only
16bit stereo samples natively.  The others are covered by alsa-lib,
and this involves with the mmap mode.

But I still wonder why 16bit mode.

OK, the below is *THE* test I'd like ask you guys to try first.

- Build the driver with --with-debug=detect option
- Load the driver with debug=2 module option
- Prepare a WAV file with 96kHz 16bit stereo, e.g. converted via sox
- Raise the Master volume to the max
- Run "aplay this.wav"

At *each* run, check your kernel message.  If you get Oops, copy the
whole log immediately.

- If you get a DMA error or so in the kernel message, try to define
  XXX_SYSTEM_TIMER in sbxfi.c, rebuild and reinstall the driver.
  Run the same test.

- If still any serious problem, load the module with debug=3 option,
  and get the whole kernel message with full register accesses.


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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

Takashi Iwai пишет:
> At Tue, 14 Oct 2008 15:24:22 +0400,
> The Source wrote:
>   
>> By the way, note, that not rate may cause oops but number of channles 
>> for example (wav that causes oops has mono mode and the one that just 
>> plays silently - stereo. Also the oops sample is 16bit, silent one is 
>> 24bit).
>>     
>
> This is an important information.  The driver basically supports only
> 16bit stereo samples natively.  The others are covered by alsa-lib,
> and this involves with the mmap mode.
>
> But I still wonder why 16bit mode.
>
> OK, the below is *THE* test I'd like ask you guys to try first.
>
> - Build the driver with --with-debug=detect option
> - Load the driver with debug=2 module option
> - Prepare a WAV file with 96kHz 16bit stereo, e.g. converted via sox
> - Raise the Master volume to the max
> - Run "aplay this.wav"
>
> At *each* run, check your kernel message.  If you get Oops, copy the
> whole log immediately.
>
> - If you get a DMA error or so in the kernel message, try to define
>   XXX_SYSTEM_TIMER in sbxfi.c, rebuild and reinstall the driver.
>   Run the same test.
>
> - If still any serious problem, load the module with debug=3 option,
>   and get the whole kernel message with full register accesses.
>
>
> thanks,
>
> Takashi
>
>   
I've done what you have asked. I've got no oopses or other things like 
that. But again not sound. I've tried with debug=2 and debug=3. 
Attaching the whole dmesg output.

[-- Attachment #2: dmesg.out.bz2 --]
[-- Type: application/x-bzip, Size: 14969 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 15 Oct 2008 11:16:32 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Tue, 14 Oct 2008 15:24:22 +0400,
> > The Source wrote:
> >   
> >> By the way, note, that not rate may cause oops but number of channles 
> >> for example (wav that causes oops has mono mode and the one that just 
> >> plays silently - stereo. Also the oops sample is 16bit, silent one is 
> >> 24bit).
> >>     
> >
> > This is an important information.  The driver basically supports only
> > 16bit stereo samples natively.  The others are covered by alsa-lib,
> > and this involves with the mmap mode.
> >
> > But I still wonder why 16bit mode.
> >
> > OK, the below is *THE* test I'd like ask you guys to try first.
> >
> > - Build the driver with --with-debug=detect option
> > - Load the driver with debug=2 module option
> > - Prepare a WAV file with 96kHz 16bit stereo, e.g. converted via sox
> > - Raise the Master volume to the max
> > - Run "aplay this.wav"
> >
> > At *each* run, check your kernel message.  If you get Oops, copy the
> > whole log immediately.
> >
> > - If you get a DMA error or so in the kernel message, try to define
> >   XXX_SYSTEM_TIMER in sbxfi.c, rebuild and reinstall the driver.
> >   Run the same test.
> >
> > - If still any serious problem, load the module with debug=3 option,
> >   and get the whole kernel message with full register accesses.
> >
> >
> > thanks,
> >
> > Takashi
> >
> >   
> I've done what you have asked. I've got no oopses or other things like 
> that. But again not sound. I've tried with debug=2 and debug=3. 
> Attaching the whole dmesg output.

Thanks.  Judging from your logs, it seems that the timer IRQ isn't
generated as expected, or the pointer (SRCCA register read) doesn't
work, or all broken.

Could you try with XXX_SYSTEM_TIMER?  This eliminates, at least, the
timer issue.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 15 Oct 2008 11:47:00 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Wed, 15 Oct 2008 11:16:32 +0400,
> > The Source wrote:
> >   
> >> Takashi Iwai пишет:
> >>     
> >>> At Tue, 14 Oct 2008 15:24:22 +0400,
> >>> The Source wrote:
> >>>   
> >>>       
> >>>> By the way, note, that not rate may cause oops but number of channles 
> >>>> for example (wav that causes oops has mono mode and the one that just 
> >>>> plays silently - stereo. Also the oops sample is 16bit, silent one is 
> >>>> 24bit).
> >>>>     
> >>>>         
> >>> This is an important information.  The driver basically supports only
> >>> 16bit stereo samples natively.  The others are covered by alsa-lib,
> >>> and this involves with the mmap mode.
> >>>
> >>> But I still wonder why 16bit mode.
> >>>
> >>> OK, the below is *THE* test I'd like ask you guys to try first.
> >>>
> >>> - Build the driver with --with-debug=detect option
> >>> - Load the driver with debug=2 module option
> >>> - Prepare a WAV file with 96kHz 16bit stereo, e.g. converted via sox
> >>> - Raise the Master volume to the max
> >>> - Run "aplay this.wav"
> >>>
> >>> At *each* run, check your kernel message.  If you get Oops, copy the
> >>> whole log immediately.
> >>>
> >>> - If you get a DMA error or so in the kernel message, try to define
> >>>   XXX_SYSTEM_TIMER in sbxfi.c, rebuild and reinstall the driver.
> >>>   Run the same test.
> >>>
> >>> - If still any serious problem, load the module with debug=3 option,
> >>>   and get the whole kernel message with full register accesses.
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>>   
> >>>       
> >> I've done what you have asked. I've got no oopses or other things like 
> >> that. But again not sound. I've tried with debug=2 and debug=3. 
> >> Attaching the whole dmesg output.
> >>     
> >
> > Thanks.  Judging from your logs, it seems that the timer IRQ isn't
> > generated as expected, or the pointer (SRCCA register read) doesn't
> > work, or all broken.
> >
> > Could you try with XXX_SYSTEM_TIMER?  This eliminates, at least, the
> > timer issue.
> >
> >
> > Takashi
> >
> >   
> I can't use system timer. changing #undef XXX_SYSTEM_TIMER to #define 
> XXX_SYSTEM_TIMER causes this:
> In file included from /mnt/e/temp/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2:
> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: 
> In function ‘sbxfi_timer_handle’:
> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
> error: ‘status’ undeclared (first use in this function)
> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
> error: (Each undeclared identifier is reported only once
> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
> error: for each function it appears in.)
> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
> warning: too many arguments for format

Try the patch below.  In case you're using snapshot tarball, apply it
with -p2 on alsa-kernel directory.


Takashi

diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
index 9ff5fc4..d6b5b34 100644
--- a/sound/pci/sbxfi/sbxfi.c
+++ b/sound/pci/sbxfi/sbxfi.c
@@ -249,7 +249,7 @@ static void sbxfi_handle_timer_callback(struct sbxfi *chip);
 
 static void sbxfi_timer_handle(unsigned long data)
 {
-	LOG(2, "TIMER ISR\n", status);
+	LOG(2, "TIMER ISR\n");
 	sbxfi_handle_timer_callback((struct sbxfi *)data);
 }
 

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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

Takashi Iwai пишет:
> At Wed, 15 Oct 2008 11:47:00 +0400,
> The Source wrote:
>   
>> Takashi Iwai пишет:
>>     
>>> At Wed, 15 Oct 2008 11:16:32 +0400,
>>> The Source wrote:
>>>   
>>>       
>>>> Takashi Iwai пишет:
>>>>     
>>>>         
>>>>> At Tue, 14 Oct 2008 15:24:22 +0400,
>>>>> The Source wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> By the way, note, that not rate may cause oops but number of channles 
>>>>>> for example (wav that causes oops has mono mode and the one that just 
>>>>>> plays silently - stereo. Also the oops sample is 16bit, silent one is 
>>>>>> 24bit).
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> This is an important information.  The driver basically supports only
>>>>> 16bit stereo samples natively.  The others are covered by alsa-lib,
>>>>> and this involves with the mmap mode.
>>>>>
>>>>> But I still wonder why 16bit mode.
>>>>>
>>>>> OK, the below is *THE* test I'd like ask you guys to try first.
>>>>>
>>>>> - Build the driver with --with-debug=detect option
>>>>> - Load the driver with debug=2 module option
>>>>> - Prepare a WAV file with 96kHz 16bit stereo, e.g. converted via sox
>>>>> - Raise the Master volume to the max
>>>>> - Run "aplay this.wav"
>>>>>
>>>>> At *each* run, check your kernel message.  If you get Oops, copy the
>>>>> whole log immediately.
>>>>>
>>>>> - If you get a DMA error or so in the kernel message, try to define
>>>>>   XXX_SYSTEM_TIMER in sbxfi.c, rebuild and reinstall the driver.
>>>>>   Run the same test.
>>>>>
>>>>> - If still any serious problem, load the module with debug=3 option,
>>>>>   and get the whole kernel message with full register accesses.
>>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Takashi
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> I've done what you have asked. I've got no oopses or other things like 
>>>> that. But again not sound. I've tried with debug=2 and debug=3. 
>>>> Attaching the whole dmesg output.
>>>>     
>>>>         
>>> Thanks.  Judging from your logs, it seems that the timer IRQ isn't
>>> generated as expected, or the pointer (SRCCA register read) doesn't
>>> work, or all broken.
>>>
>>> Could you try with XXX_SYSTEM_TIMER?  This eliminates, at least, the
>>> timer issue.
>>>
>>>
>>> Takashi
>>>
>>>   
>>>       
>> I can't use system timer. changing #undef XXX_SYSTEM_TIMER to #define 
>> XXX_SYSTEM_TIMER causes this:
>> In file included from /mnt/e/temp/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2:
>> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: 
>> In function ‘sbxfi_timer_handle’:
>> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
>> error: ‘status’ undeclared (first use in this function)
>> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
>> error: (Each undeclared identifier is reported only once
>> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
>> error: for each function it appears in.)
>> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
>> warning: too many arguments for format
>>     
>
> Try the patch below.  In case you're using snapshot tarball, apply it
> with -p2 on alsa-kernel directory.
>
>
> Takashi
>
> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> index 9ff5fc4..d6b5b34 100644
> --- a/sound/pci/sbxfi/sbxfi.c
> +++ b/sound/pci/sbxfi/sbxfi.c
> @@ -249,7 +249,7 @@ static void sbxfi_handle_timer_callback(struct sbxfi *chip);
>  
>  static void sbxfi_timer_handle(unsigned long data)
>  {
> -	LOG(2, "TIMER ISR\n", status);
> +	LOG(2, "TIMER ISR\n");
>  	sbxfi_handle_timer_callback((struct sbxfi *)data);
>  }
>  
>
>
>   
Ok, I tested again and found that sound is actually played (with and 
without system timer), but:
1. The volume is extremely low. I had not only set volume to maximum in  
alsamixer but also set my audio 5.1 system volume to maximum to hear a 
sound.
2. The sound is very slow and glitchy. It plays much slower that it 
should and constant glitches occur.

Attaching dmesg output.


[-- Attachment #2: dmesg.out.bz2 --]
[-- Type: application/x-bzip, Size: 5221 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

On Wed, 15 Oct 2008 08:30:20 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Wed, 15 Oct 2008 00:35:31 +0400,
> Alexey Bazhin wrote:
> > 
> > On Tue, 14 Oct 2008 08:45:20 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Mon, 13 Oct 2008 23:21:47 +0400,
> > > Alexey Bazhin wrote:
> > > > 
> > > > Now it doesn't hangs :)
> > > 
> > > Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any
> > > workaround needed?  Or, did it work as is?
> > > 
> > > > but speakers-test produces crackling sine and
> > > > fails on test...
> > > 
> > > Do you mean it aborts some time later after starting the stream?
> > > Could you show the kernel messages?  The default debug level
> > > should suffice, I guess.  If any, try debug=2.
> > 
> > root@mayonaka:~/linux-2.6# dmesg -c >/dev/null
> > root@mayonaka:~/linux-2.6# insmod sound/pci/sbxfi/snd-sbxfi.ko
> > root@mayonaka:~/linux-2.6# dmesg
> > [ 2957.493602] SBXFI: INIT HW
> > [ 2957.596133] SBXFI: Setting TLB buffer page 0xc02000
> > root@mayonaka:~/linux-2.6# speaker-test -c 2 -r 96000 -t sine
> > 
> > speaker-test 1.0.15
> > 
> > Playback device is default
> > Stream parameters are 96000Hz, S16_LE, 2 channels
> > Sine wave rate is 440.0000Hz
> > Rate set to 96000Hz (requested 96000Hz)
> > Buffer size range from 32 to 16384
> > Period size range from 32 to 16384
> > Using max buffer size 16384
> > Periods = 4
> > was set period_size = 4096
> > was set buffer_size = 16384
> >  0 - Front Left
> > 
> > 
> > 
> > Write error: -5,Input/output error
> > xrun_recovery failed: -5,Input/output error
> > Transfer failed: Operation not permitted
> > root@mayonaka:~/linux-2.6# 
> > root@mayonaka:~/linux-2.6# dmesg
> > [ 2957.493602] SBXFI: INIT HW
> > [ 2957.596133] SBXFI: Setting TLB buffer page 0xc02000
> > [ 2974.854578] SBXFI: Allocate SRC 0
> > [ 2974.855368] SBXFI: allocated TLB at 0 for 16 pages
> > [ 2974.855372] SBXFI: filled TLB pages starting at 0xc10000
> > [ 2974.855393] SBXFI: PLAYBACK PREPARE: rate=96000,
> > period_size=4096, buffer_size=16384
> > [ 2974.855396] SBXFI: INIT DAC
> > [ 2974.855400] SBXFI: RESET DAC
> > [ 2975.059435] SBXFI: SETUP I2S
> > [ 2975.059445] SBXFI: Pitch [0:fa6] = 0x1000000
> > [ 2975.059449] SBXFI: Pitch [80:7a6] = 0x1000000
> > [ 2975.059453] SBXFI: Pitch [1:fb6] = 0x1000000
> > [ 2975.059456] SBXFI: Pitch [81:7b6] = 0x1000000
> > [ 2975.059460] SBXFI: Amp [00:0001] = 0x101c
> > [ 2975.059465] SBXFI: Amp [80:07a6] = 0x101c
> > [ 2975.059470] SBXFI: Amp [01:0011] = 0x101c
> > [ 2975.059474] SBXFI: Amp [81:07b6] = 0x101c
> > [ 2975.062594] SBXFI: PLAY TRIGGER START
> > [ 2975.062600] SBXFI: SETUP SRC: ch=0x0, start=0x0, loop=0x10000,
> > cache=0x100, ctrl=0x1045c 
> > [ 2975.062612] SBXFI: SETUP SRC: ch=0x1, start=0x0, loop=0x10000,
> > cache=0x100, ctrl=0x5c
> > [ 2975.062625] SBXFI: PLAY UPDATE TIMER
> > [ 2995.148059] SBXFI: PLAY TRIGGER STOP
> > [ 2995.148072] SBXFI: PLAY UPDATE TIMER
> > [ 2995.148079] SBXFI: release TLB at 0 for 16 pages
> > [ 2995.148218] SBXFI: Release SRC 0
> 
> Hmm, then there is no serious error here.  Did you build the driver
> with --with-debug=full or --with-debug=detect option?
No, i'm just building kernel from git with your tree.

> Also, run with debug=2.  Then it prints the timer/IRQ handling, too.
> 
> Does this happen with aplay, too?
> 
> Also, please track via strace to check which syscall it gets an error.
I'll try it later, sorry...

> > Two more things:
> > -speakers-test on 48khz doesn't produce above errors, but frequency
> > is still not right
> 
> OK, let's postpone this issue.
> 
> > -24-bit samples is silent for me too
> 
> Too?  What are other cases that cause silent output?
I saw that "The Source <thesourcehim@gmail.com>" was trying to play
only 24-bit 96khz samples and they were silent.

> Also, can you check whether "aplay -M foo.wav" (with 96khz sound file)
> gives any output?
> 
> > > How about the patch below for 48kHz?
> > Didn't changed anything...
> 
> OK.  Just to make clear: you get any (more or less) reasonable sound,
> not silent, with 96kHz stereo, right?
Yes, on 96khz 16bit stereo only

> If yes, then there seems a difference between machines or
> environments.  Could you clarify your system again?
> 
> 
> Takashi


-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 15 Oct 2008 12:26:49 +0400,
Alexey Bazhin wrote:
> 
> On Wed, 15 Oct 2008 08:30:20 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Wed, 15 Oct 2008 00:35:31 +0400,
> > Alexey Bazhin wrote:
> > > 
> > > On Tue, 14 Oct 2008 08:45:20 +0200
> > > Takashi Iwai <tiwai@suse.de> wrote:
> > > 
> > > > At Mon, 13 Oct 2008 23:21:47 +0400,
> > > > Alexey Bazhin wrote:
> > > > > 
> > > > > Now it doesn't hangs :)
> > > > 
> > > > Glad to hear.  Did you have to use XXX_SYSTEM_TIMER or any
> > > > workaround needed?  Or, did it work as is?
> > > > 
> > > > > but speakers-test produces crackling sine and
> > > > > fails on test...
> > > > 
> > > > Do you mean it aborts some time later after starting the stream?
> > > > Could you show the kernel messages?  The default debug level
> > > > should suffice, I guess.  If any, try debug=2.
> > > 
> > > root@mayonaka:~/linux-2.6# dmesg -c >/dev/null
> > > root@mayonaka:~/linux-2.6# insmod sound/pci/sbxfi/snd-sbxfi.ko
> > > root@mayonaka:~/linux-2.6# dmesg
> > > [ 2957.493602] SBXFI: INIT HW
> > > [ 2957.596133] SBXFI: Setting TLB buffer page 0xc02000
> > > root@mayonaka:~/linux-2.6# speaker-test -c 2 -r 96000 -t sine
> > > 
> > > speaker-test 1.0.15
> > > 
> > > Playback device is default
> > > Stream parameters are 96000Hz, S16_LE, 2 channels
> > > Sine wave rate is 440.0000Hz
> > > Rate set to 96000Hz (requested 96000Hz)
> > > Buffer size range from 32 to 16384
> > > Period size range from 32 to 16384
> > > Using max buffer size 16384
> > > Periods = 4
> > > was set period_size = 4096
> > > was set buffer_size = 16384
> > >  0 - Front Left
> > > 
> > > 
> > > 
> > > Write error: -5,Input/output error
> > > xrun_recovery failed: -5,Input/output error
> > > Transfer failed: Operation not permitted
> > > root@mayonaka:~/linux-2.6# 
> > > root@mayonaka:~/linux-2.6# dmesg
> > > [ 2957.493602] SBXFI: INIT HW
> > > [ 2957.596133] SBXFI: Setting TLB buffer page 0xc02000
> > > [ 2974.854578] SBXFI: Allocate SRC 0
> > > [ 2974.855368] SBXFI: allocated TLB at 0 for 16 pages
> > > [ 2974.855372] SBXFI: filled TLB pages starting at 0xc10000
> > > [ 2974.855393] SBXFI: PLAYBACK PREPARE: rate=96000,
> > > period_size=4096, buffer_size=16384
> > > [ 2974.855396] SBXFI: INIT DAC
> > > [ 2974.855400] SBXFI: RESET DAC
> > > [ 2975.059435] SBXFI: SETUP I2S
> > > [ 2975.059445] SBXFI: Pitch [0:fa6] = 0x1000000
> > > [ 2975.059449] SBXFI: Pitch [80:7a6] = 0x1000000
> > > [ 2975.059453] SBXFI: Pitch [1:fb6] = 0x1000000
> > > [ 2975.059456] SBXFI: Pitch [81:7b6] = 0x1000000
> > > [ 2975.059460] SBXFI: Amp [00:0001] = 0x101c
> > > [ 2975.059465] SBXFI: Amp [80:07a6] = 0x101c
> > > [ 2975.059470] SBXFI: Amp [01:0011] = 0x101c
> > > [ 2975.059474] SBXFI: Amp [81:07b6] = 0x101c
> > > [ 2975.062594] SBXFI: PLAY TRIGGER START
> > > [ 2975.062600] SBXFI: SETUP SRC: ch=0x0, start=0x0, loop=0x10000,
> > > cache=0x100, ctrl=0x1045c 
> > > [ 2975.062612] SBXFI: SETUP SRC: ch=0x1, start=0x0, loop=0x10000,
> > > cache=0x100, ctrl=0x5c
> > > [ 2975.062625] SBXFI: PLAY UPDATE TIMER
> > > [ 2995.148059] SBXFI: PLAY TRIGGER STOP
> > > [ 2995.148072] SBXFI: PLAY UPDATE TIMER
> > > [ 2995.148079] SBXFI: release TLB at 0 for 16 pages
> > > [ 2995.148218] SBXFI: Release SRC 0
> > 
> > Hmm, then there is no serious error here.  Did you build the driver
> > with --with-debug=full or --with-debug=detect option?
> No, i'm just building kernel from git with your tree.

In that case, make sure you having CONFIG_SND_DEBUG=y at least.
CONFIG_SND_DEBUG_VERBOSE=y would give you more, but not mandatory
as sbxfi.c doesn't use snd_printdd() much.

> > Also, run with debug=2.  Then it prints the timer/IRQ handling, too.
> > 
> > Does this happen with aplay, too?
> > 
> > Also, please track via strace to check which syscall it gets an error.
> I'll try it later, sorry...

I guess it's a timer issue.  Try to define XXX_SYSTEM_TIMER and rebuild
(and pull the latest GIT before that, since it had a bug).

> > > Two more things:
> > > -speakers-test on 48khz doesn't produce above errors, but frequency
> > > is still not right
> > 
> > OK, let's postpone this issue.
> > 
> > > -24-bit samples is silent for me too
> > 
> > Too?  What are other cases that cause silent output?
> I saw that "The Source <thesourcehim@gmail.com>" was trying to play
> only 24-bit 96khz samples and they were silent.

Ah OK.  Yes, this seems explaining the symptom (but not the cause :)


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 15 Oct 2008 12:14:57 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Wed, 15 Oct 2008 11:47:00 +0400,
> > The Source wrote:
> >   
> >> Takashi Iwai пишет:
> >>     
> >>> At Wed, 15 Oct 2008 11:16:32 +0400,
> >>> The Source wrote:
> >>>   
> >>>       
> >>>> Takashi Iwai пишет:
> >>>>     
> >>>>         
> >>>>> At Tue, 14 Oct 2008 15:24:22 +0400,
> >>>>> The Source wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> By the way, note, that not rate may cause oops but number of channles 
> >>>>>> for example (wav that causes oops has mono mode and the one that just 
> >>>>>> plays silently - stereo. Also the oops sample is 16bit, silent one is 
> >>>>>> 24bit).
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> This is an important information.  The driver basically supports only
> >>>>> 16bit stereo samples natively.  The others are covered by alsa-lib,
> >>>>> and this involves with the mmap mode.
> >>>>>
> >>>>> But I still wonder why 16bit mode.
> >>>>>
> >>>>> OK, the below is *THE* test I'd like ask you guys to try first.
> >>>>>
> >>>>> - Build the driver with --with-debug=detect option
> >>>>> - Load the driver with debug=2 module option
> >>>>> - Prepare a WAV file with 96kHz 16bit stereo, e.g. converted via sox
> >>>>> - Raise the Master volume to the max
> >>>>> - Run "aplay this.wav"
> >>>>>
> >>>>> At *each* run, check your kernel message.  If you get Oops, copy the
> >>>>> whole log immediately.
> >>>>>
> >>>>> - If you get a DMA error or so in the kernel message, try to define
> >>>>>   XXX_SYSTEM_TIMER in sbxfi.c, rebuild and reinstall the driver.
> >>>>>   Run the same test.
> >>>>>
> >>>>> - If still any serious problem, load the module with debug=3 option,
> >>>>>   and get the whole kernel message with full register accesses.
> >>>>>
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> I've done what you have asked. I've got no oopses or other things like 
> >>>> that. But again not sound. I've tried with debug=2 and debug=3. 
> >>>> Attaching the whole dmesg output.
> >>>>     
> >>>>         
> >>> Thanks.  Judging from your logs, it seems that the timer IRQ isn't
> >>> generated as expected, or the pointer (SRCCA register read) doesn't
> >>> work, or all broken.
> >>>
> >>> Could you try with XXX_SYSTEM_TIMER?  This eliminates, at least, the
> >>> timer issue.
> >>>
> >>>
> >>> Takashi
> >>>
> >>>   
> >>>       
> >> I can't use system timer. changing #undef XXX_SYSTEM_TIMER to #define 
> >> XXX_SYSTEM_TIMER causes this:
> >> In file included from /mnt/e/temp/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2:
> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: 
> >> In function ‘sbxfi_timer_handle’:
> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
> >> error: ‘status’ undeclared (first use in this function)
> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
> >> error: (Each undeclared identifier is reported only once
> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
> >> error: for each function it appears in.)
> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: 
> >> warning: too many arguments for format
> >>     
> >
> > Try the patch below.  In case you're using snapshot tarball, apply it
> > with -p2 on alsa-kernel directory.
> >
> >
> > Takashi
> >
> > diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > index 9ff5fc4..d6b5b34 100644
> > --- a/sound/pci/sbxfi/sbxfi.c
> > +++ b/sound/pci/sbxfi/sbxfi.c
> > @@ -249,7 +249,7 @@ static void sbxfi_handle_timer_callback(struct sbxfi *chip);
> >  
> >  static void sbxfi_timer_handle(unsigned long data)
> >  {
> > -	LOG(2, "TIMER ISR\n", status);
> > +	LOG(2, "TIMER ISR\n");
> >  	sbxfi_handle_timer_callback((struct sbxfi *)data);
> >  }
> >  
> >
> >
> >   
> Ok, I tested again and found that sound is actually played (with and 
> without system timer),

Good to hear a positive thing :)

> but:
> 1. The volume is extremely low. I had not only set volume to maximum in  
> alsamixer but also set my audio 5.1 system volume to maximum to hear a 
> sound.

This sounds like an amp isn't turned on somewhere.  Possibly a GPIO
setting.

Alexey, what about your hardware?  Is it also so extremely low?

> 2. The sound is very slow and glitchy. It plays much slower that it 
> should and constant glitches occur.

The glitches might be the result of the rate inconsistency.
How slow is it?  Is it somewhat playing half-rate samples?  You can
check it on the normally running device, for example,

	% aplay -traw -fS16_LE -c2 -r48000 SOME-96K.wav

will play 96kHz samples in 48kHz.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

On Wed, 15 Oct 2008 11:07:17 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Wed, 15 Oct 2008 12:14:57 +0400,
> The Source wrote: 
> > but:
> > 1. The volume is extremely low. I had not only set volume to
> > maximum in alsamixer but also set my audio 5.1 system volume to
> > maximum to hear a sound.
> 
> This sounds like an amp isn't turned on somewhere.  Possibly a GPIO
> setting.
> 
> Alexey, what about your hardware?  Is it also so extremely low?
No, volume is fine.


-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

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

On Wed, 15 Oct 2008 11:02:46 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Wed, 15 Oct 2008 12:26:49 +0400,
> Alexey Bazhin wrote:
> > 
> > On Wed, 15 Oct 2008 08:30:20 +0200
> > Takashi Iwai <tiwai@suse.de> wrote:
> > 
> > > At Wed, 15 Oct 2008 00:35:31 +0400,
> > > Alexey Bazhin wrote:
> > > > 
> > > > On Tue, 14 Oct 2008 08:45:20 +0200
> > > > Takashi Iwai <tiwai@suse.de> wrote:
> > > > 
> > > > > > but speakers-test produces crackling sine and
> > > > > > fails on test...
> > > > > 
> > > > > Do you mean it aborts some time later after starting the
> > > > > stream? Could you show the kernel messages?  The default
> > > > > debug level should suffice, I guess.  If any, try debug=2.
> > > > 
> > > > root@mayonaka:~/linux-2.6# speaker-test -c 2 -r 96000 -t sine
> > > > 
> > > > speaker-test 1.0.15
> > > > 
> > > > Playback device is default
> > > > Stream parameters are 96000Hz, S16_LE, 2 channels
> > > > Sine wave rate is 440.0000Hz
> > > > Rate set to 96000Hz (requested 96000Hz)
> > > > Buffer size range from 32 to 16384
> > > > Period size range from 32 to 16384
> > > > Using max buffer size 16384
> > > > Periods = 4
> > > > was set period_size = 4096
> > > > was set buffer_size = 16384
> > > >  0 - Front Left
> > > > 
> > > > 
> > > > 
> > > > Write error: -5,Input/output error
> > > > xrun_recovery failed: -5,Input/output error
> > > > Transfer failed: Operation not permitted
> > > 
> > > Hmm, then there is no serious error here.  Did you build the
> > > driver with --with-debug=full or --with-debug=detect option?
> > No, i'm just building kernel from git with your tree.
> 
> In that case, make sure you having CONFIG_SND_DEBUG=y at least.
> CONFIG_SND_DEBUG_VERBOSE=y would give you more, but not mandatory
> as sbxfi.c doesn't use snd_printdd() much.
> 
> > > Also, run with debug=2.  Then it prints the timer/IRQ handling,
> > > too.
[  374.731135] SBXFI: IRQ = 0x500
[  374.731287] SBXFI: IRQ = 0x500
[  376.192674] SBXFI: IRQ = 0x500
[  376.192800] SBXFI: IRQ = 0x500
[  376.192815] SBXFI: IRQ = 0x500
[  376.198822] SBXFI: Allocate SRC 0
[  376.199099] SBXFI: IRQ = 0x500
[  376.199888] SBXFI: allocated TLB at 0 for 16 pages
[  376.199891] SBXFI: filled TLB pages starting at 0xc10000
[  376.199913] SBXFI: PLAYBACK PREPARE: rate=96000, period_size=4096,
buffer_size=16384
[  376.199916] SBXFI: INIT DAC
[  376.199920] SBXFI: RESET DAC
[  376.400474] SBXFI: IRQ = 0x500
[  376.403443] SBXFI: SETUP I2S
[  376.403451] SBXFI: Pitch [0:fa6] = 0x1000000
[  376.403455] SBXFI: Pitch [80:7a6] = 0x1000000
[  376.403458] SBXFI: Pitch [1:fb6] = 0x1000000
[  376.403462] SBXFI: Pitch [81:7b6] = 0x1000000
[  376.403466] SBXFI: Amp [00:0001] = 0x101c
[  376.403471] SBXFI: Amp [80:07a6] = 0x101c
[  376.403476] SBXFI: Amp [01:0011] = 0x101c
[  376.403480] SBXFI: Amp [81:07b6] = 0x101c
[  376.403485] SBXFI: DAOIMAP CLEAR
[  376.405447] SBXFI: PLAY TRIGGER START
[  376.405450] SBXFI: SETUP SRC: ch=0x0, start=0x0, loop=0x10000,
cache=0x100, ctrl=0x1045c
[  376.405462] SBXFI: SETUP SRC: ch=0x1, start=0x0, loop=0x10000,
cache=0x100, ctrl=0x5c
[  376.405475] SBXFI: PLAY UPDATE TIMER
[  376.405478] SBXFI: POINTER = 0x0
[  376.405480] SBXFI: SET TIMER TICKS = 4096
[  376.405924] SBXFI: POINTER = 0x2a
[  376.405927] SBXFI: POINTER = 0x2b
[  376.405931] SBXFI: POINTER = 0x2b
[  376.406007] SBXFI: IRQ = 0x400
[  376.490861] SBXFI: IRQ = 0x500
[  376.490866] SBXFI: POINTER = 0x2004
[  376.490868] SBXFI: SET TIMER TICKS = 16388
[  376.490873] SBXFI: POINTER = 0x2005
[  376.491692] SBXFI: POINTER = 0x2054
[  376.492144] SBXFI: POINTER = 0x207f
[  376.492148] SBXFI: POINTER = 0x207f
[  376.661562] SBXFI: IRQ = 0x500
[  376.661567] SBXFI: POINTER = 0x2006
[  376.661569] SBXFI: SET TIMER TICKS = 20486
[  376.661573] SBXFI: POINTER = 0x2007
[  376.832263] SBXFI: IRQ = 0x500
[  376.832268] SBXFI: POINTER = 0x2008
[  376.832269] SBXFI: SET TIMER TICKS = 24584
[  376.832274] SBXFI: POINTER = 0x2009
[  377.002957] SBXFI: IRQ = 0x500
[  377.002962] SBXFI: POINTER = 0x200a
[  377.002963] SBXFI: SET TIMER TICKS = 28682
[  377.002968] SBXFI: POINTER = 0x200b
[  377.173658] SBXFI: IRQ = 0x500
[  377.173663] SBXFI: POINTER = 0x200c
[  377.173664] SBXFI: SET TIMER TICKS = 32780
[  377.173669] SBXFI: POINTER = 0x200d
[  377.344359] SBXFI: IRQ = 0x500
[  377.344364] SBXFI: POINTER = 0x200e
[  377.344366] SBXFI: SET TIMER TICKS = 36878
[  377.344371] SBXFI: POINTER = 0x200f
[  377.515053] SBXFI: IRQ = 0x500
[  377.515058] SBXFI: POINTER = 0x2010
[  377.515060] SBXFI: SET TIMER TICKS = 40976
[  377.515065] SBXFI: POINTER = 0x2011
[  377.685754] SBXFI: IRQ = 0x500
[  377.685759] SBXFI: POINTER = 0x2012
[  377.685761] SBXFI: SET TIMER TICKS = 45074
[  377.685765] SBXFI: POINTER = 0x2013
[  377.856455] SBXFI: IRQ = 0x500
[  377.856461] SBXFI: POINTER = 0x2015
[  377.856463] SBXFI: SET TIMER TICKS = 49173
[  377.856468] SBXFI: POINTER = 0x2015
[  378.027150] SBXFI: IRQ = 0x500
[  378.027155] SBXFI: POINTER = 0x2016
[  378.027156] SBXFI: SET TIMER TICKS = 53270
[  378.027161] SBXFI: POINTER = 0x2017
[  378.197850] SBXFI: IRQ = 0x500
[  378.197855] SBXFI: POINTER = 0x2018
[  378.197857] SBXFI: SET TIMER TICKS = 57368
[  378.197862] SBXFI: POINTER = 0x2019
[  378.368551] SBXFI: IRQ = 0x500
[  378.368556] SBXFI: POINTER = 0x201a
[  378.368558] SBXFI: SET TIMER TICKS = 61466
[  378.368563] SBXFI: POINTER = 0x201b
[  378.539246] SBXFI: IRQ = 0x500
[  378.539251] SBXFI: POINTER = 0x201c
[  378.539252] SBXFI: SET TIMER TICKS = 65564
[  378.539257] SBXFI: POINTER = 0x201d
[  378.709946] SBXFI: IRQ = 0x500
[  378.709951] SBXFI: POINTER = 0x201e
[  378.709953] SBXFI: SET TIMER TICKS = 69662
[  378.709958] SBXFI: POINTER = 0x201f
[  378.880647] SBXFI: IRQ = 0x500
[  378.880652] SBXFI: POINTER = 0x2020
[  378.880654] SBXFI: SET TIMER TICKS = 73760
[  378.880659] SBXFI: POINTER = 0x2021
[  379.051342] SBXFI: IRQ = 0x500
[  379.051347] SBXFI: POINTER = 0x2022
[  379.051349] SBXFI: SET TIMER TICKS = 77858
[  379.051354] SBXFI: POINTER = 0x2023
[  379.222042] SBXFI: IRQ = 0x500
[  379.222047] SBXFI: POINTER = 0x2024
[  379.222049] SBXFI: SET TIMER TICKS = 81956
[  379.222054] SBXFI: POINTER = 0x2025
[  379.392744] SBXFI: IRQ = 0x500
[  379.392749] SBXFI: POINTER = 0x2026
[  379.392750] SBXFI: SET TIMER TICKS = 86054
[  379.392755] SBXFI: POINTER = 0x2027
[  379.563438] SBXFI: IRQ = 0x500
[  379.563443] SBXFI: POINTER = 0x2028
[  379.563445] SBXFI: SET TIMER TICKS = 90152
[  379.563450] SBXFI: POINTER = 0x2029
[  379.734139] SBXFI: IRQ = 0x500
[  379.734143] SBXFI: POINTER = 0x202a
[  379.734145] SBXFI: SET TIMER TICKS = 94250
[  379.734150] SBXFI: POINTER = 0x202b
[  379.904840] SBXFI: IRQ = 0x500
[  379.904845] SBXFI: POINTER = 0x202c
[  379.904846] SBXFI: SET TIMER TICKS = 98348
[  379.904851] SBXFI: POINTER = 0x202d
[  380.075534] SBXFI: IRQ = 0x500
[  380.075539] SBXFI: POINTER = 0x202e
[  380.075541] SBXFI: SET TIMER TICKS = 102446
[  380.075546] SBXFI: POINTER = 0x202f
[  380.246235] SBXFI: IRQ = 0x500
[  380.246240] SBXFI: POINTER = 0x2030
[  380.246242] SBXFI: SET TIMER TICKS = 106544
[  380.246247] SBXFI: POINTER = 0x2031
[  380.416936] SBXFI: IRQ = 0x500
[  380.416941] SBXFI: POINTER = 0x2032
[  380.416943] SBXFI: SET TIMER TICKS = 110642
[  380.416947] SBXFI: POINTER = 0x2033
[  380.587630] SBXFI: IRQ = 0x500
[  380.587635] SBXFI: POINTER = 0x2034
[  380.587637] SBXFI: SET TIMER TICKS = 114740
[  380.587642] SBXFI: POINTER = 0x2035
[  380.758332] SBXFI: IRQ = 0x500
[  380.758336] SBXFI: POINTER = 0x2036
[  380.758338] SBXFI: SET TIMER TICKS = 118838
[  380.758343] SBXFI: POINTER = 0x2037
[  380.929032] SBXFI: IRQ = 0x500
[  380.929037] SBXFI: POINTER = 0x2038
[  380.929039] SBXFI: SET TIMER TICKS = 122936
[  380.929044] SBXFI: POINTER = 0x2039
[  381.099727] SBXFI: IRQ = 0x500
[  381.099732] SBXFI: POINTER = 0x203a
[  381.099733] SBXFI: SET TIMER TICKS = 127034
[  381.099738] SBXFI: POINTER = 0x203b
[  381.270428] SBXFI: IRQ = 0x500
[  381.270433] SBXFI: POINTER = 0x203c
[  381.270434] SBXFI: SET TIMER TICKS = 131132
[  381.270439] SBXFI: POINTER = 0x203d
[  381.441128] SBXFI: IRQ = 0x500
[  381.441133] SBXFI: POINTER = 0x203e
[  381.441135] SBXFI: SET TIMER TICKS = 135230
[  381.441140] SBXFI: POINTER = 0x203f
[  381.611823] SBXFI: IRQ = 0x500
[  381.611828] SBXFI: POINTER = 0x2040
[  381.611829] SBXFI: SET TIMER TICKS = 139328
[  381.611834] SBXFI: POINTER = 0x2041
[  381.782524] SBXFI: IRQ = 0x500
[  381.782529] SBXFI: POINTER = 0x2042
[  381.782531] SBXFI: SET TIMER TICKS = 143426
[  381.782535] SBXFI: POINTER = 0x2043
[  381.840424] SBXFI: IRQ = 0x400
[  381.953224] SBXFI: IRQ = 0x500
[  381.953229] SBXFI: POINTER = 0x2044
[  381.953231] SBXFI: SET TIMER TICKS = 147524
[  381.953236] SBXFI: POINTER = 0x2045
[  382.123919] SBXFI: IRQ = 0x500
[  382.123924] SBXFI: POINTER = 0x2046
[  382.123926] SBXFI: SET TIMER TICKS = 151622
[  382.123931] SBXFI: POINTER = 0x2047
[  382.294620] SBXFI: IRQ = 0x500
[  382.294625] SBXFI: POINTER = 0x2048
[  382.294627] SBXFI: SET TIMER TICKS = 155720
[  382.294632] SBXFI: POINTER = 0x2049
[  382.465320] SBXFI: IRQ = 0x500
[  382.465325] SBXFI: POINTER = 0x204a
[  382.465327] SBXFI: SET TIMER TICKS = 159818
[  382.465332] SBXFI: POINTER = 0x204b
[  382.636022] SBXFI: IRQ = 0x500
[  382.636027] SBXFI: POINTER = 0x204c
[  382.636029] SBXFI: SET TIMER TICKS = 163916
[  382.636033] SBXFI: POINTER = 0x204d
[  382.806716] SBXFI: IRQ = 0x500
[  382.806721] SBXFI: POINTER = 0x204e
[  382.806723] SBXFI: SET TIMER TICKS = 168014
[  382.806728] SBXFI: POINTER = 0x204f
[  382.977417] SBXFI: IRQ = 0x500
[  382.977422] SBXFI: POINTER = 0x2050
[  382.977424] SBXFI: SET TIMER TICKS = 172112
[  382.977428] SBXFI: POINTER = 0x2051
[  383.148118] SBXFI: IRQ = 0x500
[  383.148123] SBXFI: POINTER = 0x2052
[  383.148125] SBXFI: SET TIMER TICKS = 176210
[  383.148130] SBXFI: POINTER = 0x2053
[  383.318812] SBXFI: IRQ = 0x500
[  383.318817] SBXFI: POINTER = 0x2054
[  383.318819] SBXFI: SET TIMER TICKS = 180308
[  383.318824] SBXFI: POINTER = 0x2055
[  383.489513] SBXFI: IRQ = 0x500
[  383.489518] SBXFI: POINTER = 0x2056
[  383.489519] SBXFI: SET TIMER TICKS = 184406
[  383.489524] SBXFI: POINTER = 0x2057
[  383.660214] SBXFI: IRQ = 0x500
[  383.660219] SBXFI: POINTER = 0x2058
[  383.660221] SBXFI: SET TIMER TICKS = 188504
[  383.660226] SBXFI: POINTER = 0x2059
[  383.830908] SBXFI: IRQ = 0x500
[  383.830913] SBXFI: POINTER = 0x205a
[  383.830915] SBXFI: SET TIMER TICKS = 192602
[  383.830920] SBXFI: POINTER = 0x205b
[  384.001610] SBXFI: IRQ = 0x500
[  384.001615] SBXFI: POINTER = 0x205c
[  384.001617] SBXFI: SET TIMER TICKS = 196700
[  384.001621] SBXFI: POINTER = 0x205d
[  384.172310] SBXFI: IRQ = 0x500
[  384.172315] SBXFI: POINTER = 0x205e
[  384.172317] SBXFI: SET TIMER TICKS = 200798
[  384.172322] SBXFI: POINTER = 0x205f
[  384.343005] SBXFI: IRQ = 0x500
[  384.343010] SBXFI: POINTER = 0x2060
[  384.343012] SBXFI: SET TIMER TICKS = 204896
[  384.343016] SBXFI: POINTER = 0x2061
[  384.513706] SBXFI: IRQ = 0x500
[  384.513711] SBXFI: POINTER = 0x2062
[  384.513713] SBXFI: SET TIMER TICKS = 208994
[  384.513718] SBXFI: POINTER = 0x2063
[  384.684406] SBXFI: IRQ = 0x500
[  384.684412] SBXFI: POINTER = 0x2064
[  384.684414] SBXFI: SET TIMER TICKS = 213092
[  384.684419] SBXFI: POINTER = 0x2065
[  384.855101] SBXFI: IRQ = 0x500
[  384.855106] SBXFI: POINTER = 0x2066
[  384.855108] SBXFI: SET TIMER TICKS = 217190
[  384.855113] SBXFI: POINTER = 0x2067
[  385.025802] SBXFI: IRQ = 0x500
[  385.025807] SBXFI: POINTER = 0x2068
[  385.025809] SBXFI: SET TIMER TICKS = 221288
[  385.025814] SBXFI: POINTER = 0x2069
[  385.196502] SBXFI: IRQ = 0x500
[  385.196508] SBXFI: POINTER = 0x206a
[  385.196509] SBXFI: SET TIMER TICKS = 225386
[  385.196514] SBXFI: POINTER = 0x206b
[  385.367197] SBXFI: IRQ = 0x500
[  385.367202] SBXFI: POINTER = 0x206c
[  385.367204] SBXFI: SET TIMER TICKS = 229484
[  385.367209] SBXFI: POINTER = 0x206d
[  385.537898] SBXFI: IRQ = 0x500
[  385.537903] SBXFI: POINTER = 0x206e
[  385.537905] SBXFI: SET TIMER TICKS = 233582
[  385.537910] SBXFI: POINTER = 0x206f
[  385.708599] SBXFI: IRQ = 0x500
[  385.708604] SBXFI: POINTER = 0x2070
[  385.708605] SBXFI: SET TIMER TICKS = 237680
[  385.708610] SBXFI: POINTER = 0x2071
[  385.879293] SBXFI: IRQ = 0x500
[  385.879298] SBXFI: POINTER = 0x2072
[  385.879300] SBXFI: SET TIMER TICKS = 241778
[  385.879305] SBXFI: POINTER = 0x2073
[  386.049994] SBXFI: IRQ = 0x500
[  386.049999] SBXFI: POINTER = 0x2074
[  386.050001] SBXFI: SET TIMER TICKS = 245876
[  386.050006] SBXFI: POINTER = 0x2075
[  386.220695] SBXFI: IRQ = 0x500
[  386.220700] SBXFI: POINTER = 0x2076
[  386.220702] SBXFI: SET TIMER TICKS = 249974
[  386.220706] SBXFI: POINTER = 0x2077
[  386.391389] SBXFI: IRQ = 0x500
[  386.391394] SBXFI: POINTER = 0x2078
[  386.391396] SBXFI: SET TIMER TICKS = 254072
[  386.391401] SBXFI: POINTER = 0x2079
[  386.492007] ALSA sound/core/pcm_lib.c:1548: playback write error
(DMA or IRQ trouble?)
[  386.492021] SBXFI: POINTER = 0x633
[  386.562090] SBXFI: IRQ = 0x500
[  386.562095] SBXFI: POINTER = 0x207a
[  386.562097] SBXFI: SET TIMER TICKS = 258170
[  386.562102] SBXFI: POINTER = 0x207b
[  386.732792] SBXFI: IRQ = 0x500
[  386.732797] SBXFI: POINTER = 0x207c
[  386.732798] SBXFI: SET TIMER TICKS = 262268
[  386.732803] SBXFI: POINTER = 0x207d
[  386.903485] SBXFI: IRQ = 0x500
[  386.903491] SBXFI: POINTER = 0x207e
[  386.903492] SBXFI: SET TIMER TICKS = 266366
[  386.903497] SBXFI: POINTER = 0x207f
[  387.074187] SBXFI: IRQ = 0x500
[  387.074192] SBXFI: POINTER = 0x2080
[  387.074194] SBXFI: SET TIMER TICKS = 270464
[  387.074199] SBXFI: POINTER = 0x2081
[  387.244888] SBXFI: IRQ = 0x500
[  387.244893] SBXFI: POINTER = 0x2082
[  387.244895] SBXFI: SET TIMER TICKS = 274562
[  387.244899] SBXFI: POINTER = 0x2083
[  387.415582] SBXFI: IRQ = 0x500
[  387.415587] SBXFI: POINTER = 0x2084
[  387.415589] SBXFI: SET TIMER TICKS = 278660
[  387.415593] SBXFI: POINTER = 0x2085
[  387.586283] SBXFI: IRQ = 0x500
[  387.586288] SBXFI: POINTER = 0x2086
[  387.586290] SBXFI: SET TIMER TICKS = 282758
[  387.586294] SBXFI: POINTER = 0x2087
[  387.756984] SBXFI: IRQ = 0x500
[  387.756989] SBXFI: POINTER = 0x2088
[  387.756991] SBXFI: SET TIMER TICKS = 286856
[  387.756996] SBXFI: POINTER = 0x2089
[  387.927678] SBXFI: IRQ = 0x500
[  387.927683] SBXFI: POINTER = 0x208a
[  387.927685] SBXFI: SET TIMER TICKS = 290954
[  387.927689] SBXFI: POINTER = 0x208b
[  388.098379] SBXFI: IRQ = 0x500
[  388.098384] SBXFI: POINTER = 0x208c
[  388.098386] SBXFI: SET TIMER TICKS = 295052
[  388.098390] SBXFI: POINTER = 0x208d
[  388.269080] SBXFI: IRQ = 0x500
[  388.269085] SBXFI: POINTER = 0x208e
[  388.269087] SBXFI: SET TIMER TICKS = 299150
[  388.269092] SBXFI: POINTER = 0x208f
[  388.439774] SBXFI: IRQ = 0x500
[  388.439779] SBXFI: POINTER = 0x2090
[  388.439781] SBXFI: SET TIMER TICKS = 303248
[  388.439786] SBXFI: POINTER = 0x2091
[  388.610475] SBXFI: IRQ = 0x500
[  388.610480] SBXFI: POINTER = 0x2092
[  388.610482] SBXFI: SET TIMER TICKS = 307346
[  388.610487] SBXFI: POINTER = 0x2093
[  388.781176] SBXFI: IRQ = 0x500
[  388.781181] SBXFI: POINTER = 0x2094
[  388.781183] SBXFI: SET TIMER TICKS = 311444
[  388.781188] SBXFI: POINTER = 0x2095
[  388.951870] SBXFI: IRQ = 0x500
[  388.951875] SBXFI: POINTER = 0x2096
[  388.951877] SBXFI: SET TIMER TICKS = 315542
[  388.951882] SBXFI: POINTER = 0x2097
[  389.122571] SBXFI: IRQ = 0x500
[  389.122576] SBXFI: POINTER = 0x2098
[  389.122578] SBXFI: SET TIMER TICKS = 319640
[  389.122583] SBXFI: POINTER = 0x2099
[  389.293272] SBXFI: IRQ = 0x500
[  389.293277] SBXFI: POINTER = 0x209a
[  389.293279] SBXFI: SET TIMER TICKS = 323738
[  389.293284] SBXFI: POINTER = 0x209b
[  389.463966] SBXFI: IRQ = 0x500
[  389.463971] SBXFI: POINTER = 0x209c
[  389.463973] SBXFI: SET TIMER TICKS = 327836
[  389.463978] SBXFI: POINTER = 0x209d
[  389.634667] SBXFI: IRQ = 0x500
[  389.634673] SBXFI: POINTER = 0x209e
[  389.634674] SBXFI: SET TIMER TICKS = 331934
[  389.634679] SBXFI: POINTER = 0x209f
[  389.805369] SBXFI: IRQ = 0x500
[  389.805374] SBXFI: POINTER = 0x20a0
[  389.805376] SBXFI: SET TIMER TICKS = 336032
[  389.805381] SBXFI: POINTER = 0x20a1
[  389.976070] SBXFI: IRQ = 0x500
[  389.976075] SBXFI: POINTER = 0x20a2
[  389.976077] SBXFI: SET TIMER TICKS = 340130
[  389.976081] SBXFI: POINTER = 0x20a3
[  390.146764] SBXFI: IRQ = 0x500
[  390.146769] SBXFI: POINTER = 0x20a4
[  390.146770] SBXFI: SET TIMER TICKS = 344228
[  390.146775] SBXFI: POINTER = 0x20a5
[  390.317465] SBXFI: IRQ = 0x500
[  390.317470] SBXFI: POINTER = 0x20a6
[  390.317472] SBXFI: SET TIMER TICKS = 348326
[  390.317477] SBXFI: POINTER = 0x20a7
[  390.488166] SBXFI: IRQ = 0x500
[  390.488171] SBXFI: POINTER = 0x20a8
[  390.488173] SBXFI: SET TIMER TICKS = 352424
[  390.488177] SBXFI: POINTER = 0x20a9
[  390.658860] SBXFI: IRQ = 0x500
[  390.658865] SBXFI: POINTER = 0x20aa
[  390.658866] SBXFI: SET TIMER TICKS = 356522
[  390.658871] SBXFI: POINTER = 0x20ab
[  390.829561] SBXFI: IRQ = 0x500
[  390.829566] SBXFI: POINTER = 0x20ac
[  390.829568] SBXFI: SET TIMER TICKS = 360620
[  390.829573] SBXFI: POINTER = 0x20ad
[  391.000262] SBXFI: IRQ = 0x500
[  391.000267] SBXFI: POINTER = 0x20ae
[  391.000269] SBXFI: SET TIMER TICKS = 364718
[  391.000274] SBXFI: POINTER = 0x20af
[  391.170956] SBXFI: IRQ = 0x500
[  391.170961] SBXFI: POINTER = 0x20b0
[  391.170963] SBXFI: SET TIMER TICKS = 368816
[  391.170967] SBXFI: POINTER = 0x20b1
[  391.341657] SBXFI: IRQ = 0x500
[  391.341662] SBXFI: POINTER = 0x20b2
[  391.341664] SBXFI: SET TIMER TICKS = 372914
[  391.341669] SBXFI: POINTER = 0x20b3
[  391.512358] SBXFI: IRQ = 0x500
[  391.512363] SBXFI: POINTER = 0x20b4
[  391.512365] SBXFI: SET TIMER TICKS = 377012
[  391.512370] SBXFI: POINTER = 0x20b5
[  391.683052] SBXFI: IRQ = 0x500
[  391.683057] SBXFI: POINTER = 0x20b6
[  391.683059] SBXFI: SET TIMER TICKS = 381110
[  391.683064] SBXFI: POINTER = 0x20b7
[  391.853753] SBXFI: IRQ = 0x500
[  391.853758] SBXFI: POINTER = 0x20b8
[  391.853760] SBXFI: SET TIMER TICKS = 385208
[  391.853765] SBXFI: POINTER = 0x20b9
[  392.024454] SBXFI: IRQ = 0x500
[  392.024460] SBXFI: POINTER = 0x20ba
[  392.024461] SBXFI: SET TIMER TICKS = 389306
[  392.024466] SBXFI: POINTER = 0x20bb
[  392.195148] SBXFI: IRQ = 0x500
[  392.195153] SBXFI: POINTER = 0x20bc
[  392.195155] SBXFI: SET TIMER TICKS = 393404
[  392.195160] SBXFI: POINTER = 0x20bd
[  392.365849] SBXFI: IRQ = 0x500
[  392.365854] SBXFI: POINTER = 0x20be
[  392.365856] SBXFI: SET TIMER TICKS = 397502
[  392.365861] SBXFI: POINTER = 0x20bf
[  392.536550] SBXFI: IRQ = 0x500
[  392.536555] SBXFI: POINTER = 0x20c0
[  392.536557] SBXFI: SET TIMER TICKS = 401600
[  392.536562] SBXFI: POINTER = 0x20c1
[  392.707245] SBXFI: IRQ = 0x500
[  392.707250] SBXFI: POINTER = 0x20c2
[  392.707252] SBXFI: SET TIMER TICKS = 405698
[  392.707256] SBXFI: POINTER = 0x20c3
[  392.877945] SBXFI: IRQ = 0x500
[  392.877950] SBXFI: POINTER = 0x20c4
[  392.877952] SBXFI: SET TIMER TICKS = 409796
[  392.877957] SBXFI: POINTER = 0x20c5
[  393.048647] SBXFI: IRQ = 0x500
[  393.048652] SBXFI: POINTER = 0x20c6
[  393.048654] SBXFI: SET TIMER TICKS = 413894
[  393.048659] SBXFI: POINTER = 0x20c7
[  393.219341] SBXFI: IRQ = 0x500
[  393.219346] SBXFI: POINTER = 0x20c8
[  393.219348] SBXFI: SET TIMER TICKS = 417992
[  393.219353] SBXFI: POINTER = 0x20c9
[  393.390042] SBXFI: IRQ = 0x500
[  393.390047] SBXFI: POINTER = 0x20ca
[  393.390049] SBXFI: SET TIMER TICKS = 422090
[  393.390053] SBXFI: POINTER = 0x20cb
[  393.560743] SBXFI: IRQ = 0x500
[  393.560748] SBXFI: POINTER = 0x20cc
[  393.560750] SBXFI: SET TIMER TICKS = 426188
[  393.560755] SBXFI: POINTER = 0x20cd
[  393.731437] SBXFI: IRQ = 0x500
[  393.731443] SBXFI: POINTER = 0x20ce
[  393.731445] SBXFI: SET TIMER TICKS = 430286
[  393.731450] SBXFI: POINTER = 0x20cf
[  393.902138] SBXFI: IRQ = 0x500
[  393.902143] SBXFI: POINTER = 0x20d0
[  393.902145] SBXFI: SET TIMER TICKS = 434384
[  393.902149] SBXFI: POINTER = 0x20d1
[  394.072839] SBXFI: IRQ = 0x500
[  394.072844] SBXFI: POINTER = 0x20d2
[  394.072846] SBXFI: SET TIMER TICKS = 438482
[  394.072851] SBXFI: POINTER = 0x20d3
[  394.243533] SBXFI: IRQ = 0x500
[  394.243539] SBXFI: POINTER = 0x20d4
[  394.243541] SBXFI: SET TIMER TICKS = 442580
[  394.243545] SBXFI: POINTER = 0x20d5
[  394.414234] SBXFI: IRQ = 0x500
[  394.414239] SBXFI: POINTER = 0x20d6
[  394.414241] SBXFI: SET TIMER TICKS = 446678
[  394.414246] SBXFI: POINTER = 0x20d7
[  394.584935] SBXFI: IRQ = 0x500
[  394.584940] SBXFI: POINTER = 0x20d8
[  394.584942] SBXFI: SET TIMER TICKS = 450776
[  394.584947] SBXFI: POINTER = 0x20d9
[  394.755630] SBXFI: IRQ = 0x500
[  394.755635] SBXFI: POINTER = 0x20da
[  394.755636] SBXFI: SET TIMER TICKS = 454874
[  394.755641] SBXFI: POINTER = 0x20db
[  394.926330] SBXFI: IRQ = 0x500
[  394.926335] SBXFI: POINTER = 0x20dc
[  394.926337] SBXFI: SET TIMER TICKS = 458972
[  394.926342] SBXFI: POINTER = 0x20dd
[  395.097031] SBXFI: IRQ = 0x500
[  395.097036] SBXFI: POINTER = 0x20de
[  395.097038] SBXFI: SET TIMER TICKS = 463070
[  395.097043] SBXFI: POINTER = 0x20df
[  395.267726] SBXFI: IRQ = 0x500
[  395.267731] SBXFI: POINTER = 0x20e0
[  395.267733] SBXFI: SET TIMER TICKS = 467168
[  395.267738] SBXFI: POINTER = 0x20e1
[  395.438426] SBXFI: IRQ = 0x500
[  395.438431] SBXFI: POINTER = 0x20e2
[  395.438433] SBXFI: SET TIMER TICKS = 471266
[  395.438438] SBXFI: POINTER = 0x20e3
[  395.609127] SBXFI: IRQ = 0x500
[  395.609132] SBXFI: POINTER = 0x20e4
[  395.609134] SBXFI: SET TIMER TICKS = 475364
[  395.609139] SBXFI: POINTER = 0x20e5
[  395.779822] SBXFI: IRQ = 0x500
[  395.779827] SBXFI: POINTER = 0x20e6
[  395.779829] SBXFI: SET TIMER TICKS = 479462
[  395.779833] SBXFI: POINTER = 0x20e7
[  395.950523] SBXFI: IRQ = 0x500
[  395.950528] SBXFI: POINTER = 0x20e8
[  395.950530] SBXFI: SET TIMER TICKS = 483560
[  395.950535] SBXFI: POINTER = 0x20e9
[  396.121224] SBXFI: IRQ = 0x500
[  396.121229] SBXFI: POINTER = 0x20ea
[  396.121230] SBXFI: SET TIMER TICKS = 487658
[  396.121235] SBXFI: POINTER = 0x20eb
[  396.291918] SBXFI: IRQ = 0x500
[  396.291923] SBXFI: POINTER = 0x20ec
[  396.291925] SBXFI: SET TIMER TICKS = 491756
[  396.291930] SBXFI: POINTER = 0x20ed
[  396.462619] SBXFI: IRQ = 0x500
[  396.462624] SBXFI: POINTER = 0x20ee
[  396.462626] SBXFI: SET TIMER TICKS = 495854
[  396.462631] SBXFI: POINTER = 0x20ef
[  396.492007] ALSA sound/core/pcm_lib.c:1548: playback write error
(DMA or IRQ trouble?)
[  396.492071] SBXFI: PLAY TRIGGER STOP
[  396.492079] SBXFI: PLAY UPDATE TIMER
[  396.492081] SBXFI: STOP EMU TIMER
[  396.492088] SBXFI: release TLB at 0 for 16 pages
[  396.492106] SBXFI: DAOIMAP CLEAR
[  396.492226] SBXFI: Release SRC 0
[  396.492636] SBXFI: IRQ = 0x400
[  396.492737] SBXFI: IRQ = 0x400
[  399.158240] SBXFI: IRQ = 0x500
[  399.158412] SBXFI: IRQ = 0x500


> > > Does this happen with aplay, too?
Hm... with aplay I'm getting the same thing as "The Source
<thesourcehim@gmail.com>" - volume is extremely low and sound is very
glitchy. And no error as in speakers-test case. Dmesg included in
attachment.

So I'm getting almost normal sound only with
mplayer -ao alsa -af resample=96000
Dmesg in this case also included in attachment.

> > > Also, please track via strace to check which syscall it gets an
> > > error.
write(1, " 0 - Front Left\n", 16 0 - Front Left
)       = 16
ioctl(4, 0x400c4150, 0xbfd687e0)        = 0
ioctl(4, 0x400c4150, 0xbfd687e0)        = 0
ioctl(4, 0x400c4150, 0xbfd687e0)        = 0
ioctl(4, 0x400c4150, 0xbfd687e0)        = 0
ioctl(4, 0x400c4150, 0xbfd687e0)        = 0
ioctl(4, 0x400c4150, 0xbfd687e0)        = 0
ioctl(4, 0x400c4150, 0xbfd687e0)        = 0
ioctl(4, 0x400c4150, 0xbfd687e0)        = -1 EIO (Input/output error)
write(1, "Write error: -5,Input/output err"..., 35Write error:
-5,Input/output error ) = 35

> I guess it's a timer issue.  Try to define XXX_SYSTEM_TIMER and
> rebuild (and pull the latest GIT before that, since it had a bug).
Yep, no error, but sine is still glitchy. Dmesg also included.

-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

[-- Attachment #2: dmesg_aplay.txt.gz --]
[-- Type: application/x-gzip, Size: 8426 bytes --]

[-- Attachment #3: dmesg_mplayer.txt.gz --]
[-- Type: application/x-gzip, Size: 8950 bytes --]

[-- Attachment #4: dmesg_XXX_SYSTEM_TIMER.txt.gz --]
[-- Type: application/x-gzip, Size: 8116 bytes --]

[-- Attachment #5: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

>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.
>

Just wanted to help out with testing stuff.

I compiled your snapshot on my gentoo Linux x86_64

Compilation, installation and loading the drivers went smooth.

And, yes, there is sound...

Here some infos:
blub@freax $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ORIG [SB XFi (ORIG)], device 0: SB-XFi [SB-XFi]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

blub@freax $ lspci -v
01:00.0 Multimedia audio controller: Creative Labs SB X-Fi
        Subsystem: Creative Labs X-Fi Platinum
        Flags: bus master, medium devsel, latency 64, IRQ 21
        I/O ports at 8c00 [size=32]
        Memory at eb800000 (64-bit, non-prefetchable) [size=2M]
        Memory at e4000000 (64-bit, non-prefetchable) [size=64M]
        Capabilities: [40] Power Management version 2
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
        Kernel driver in use: SB-XFi


root@freax $ lsmod | grep snd
snd_pcm_oss            40640  0
snd_mixer_oss          17224  1 snd_pcm_oss
snd_seq_oss            33168  0
snd_seq_midi_event      9864  1 snd_seq_oss
snd_seq                54056  4 snd_seq_oss,snd_seq_midi_event
snd_seq_device         10076  2 snd_seq_oss,snd_seq
snd_hda_intel         505276  0
snd_hwdep              10320  1 snd_hda_intel
snd_sbxfi              23132  1
snd_pcm                81328  3 snd_pcm_oss,snd_hda_intel,snd_sbxfi
snd_timer              24160  2 snd_seq,snd_pcm
snd                    65128  12
snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_seq_device,snd_hda_intel,snd_hwdep,snd_sbxfi,snd_pcm,snd_timer
soundcore              10208  1 snd
snd_page_alloc         11664  3 snd_hda_intel,snd_sbxfi,snd_pcm

root@freax $ emerge --info
Portage 2.1.4.5 (default-linux/amd64/2007.0/desktop, gcc-4.1.2,
glibc-2.6.1-r0, 2.6.27-unpatched x86_64)

So now the funny part:

I was testing a few samplerates:
Used a 1 kHz sine, 0 dBFS, 16 bit mono wave file, 96 kHz sample rate
and rsampled it with sox:
for i in 88200 50400 50000 48000 47250 44100 44056 32000 22050 11025 8000 ; do
sox 0_16_96000.wav -r ${i} 0_16_${i}.wav ; done

and played them with aplay:

for i in 96000 88200 50400 50000 48000 47250 44100 44056 32000 22050
11025 8000 ; do echo "Now playing 0_16_${i}.wav" ; aplay 0_16_${i}.wav
; echo "DONE" ; done


96000 --> O.K.
88200 --> No Sound
50400 --> No Sound
50000 --> No Sound
48000 --> O.K.
47250 --> No Sound
44100 --> No Sound
44056 --> No Sound
32000 --> No Sound

22050 --> SYSTEM FREEZ
Playing WAVE '0_16_22050.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono

11025 --> SYSTEM FREEZ
Playing WAVE '0_16_11025.wav' : Signed 16 bit Little Endian, Rate
11025 Hz, Mono

8000 --> No Sound

Let me know if I can help out testing some more stuff

kind regards
Bjoern

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 15 Oct 2008 23:57:05 +0200,
Bjoern Olausson wrote:
> 
> So now the funny part:
> 
> I was testing a few samplerates:
> Used a 1 kHz sine, 0 dBFS, 16 bit mono wave file, 96 kHz sample rate
> and rsampled it with sox:
> for i in 88200 50400 50000 48000 47250 44100 44056 32000 22050 11025 8000 ; do
> sox 0_16_96000.wav -r ${i} 0_16_${i}.wav ; done
> 
> and played them with aplay:
> 
> for i in 96000 88200 50400 50000 48000 47250 44100 44056 32000 22050
> 11025 8000 ; do echo "Now playing 0_16_${i}.wav" ; aplay 0_16_${i}.wav
> ; echo "DONE" ; done
> 
> 
> 96000 --> O.K.

Does "O.K." mean really OK, or with any issue?
Other people reported about the glitch sounds, for example.

> 88200 --> No Sound
> 50400 --> No Sound
> 50000 --> No Sound
> 48000 --> O.K.

The same question.

> 47250 --> No Sound
> 44100 --> No Sound
> 44056 --> No Sound
> 32000 --> No Sound
> 
> 22050 --> SYSTEM FREEZ
> Playing WAVE '0_16_22050.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono

Does hang-up this happen with stereo samples, too?
Also, any chance to get Oops messages?

> 
> 11025 --> SYSTEM FREEZ
> Playing WAVE '0_16_11025.wav' : Signed 16 bit Little Endian, Rate
> 11025 Hz, Mono
> 
> 8000 --> No Sound
> 
> Let me know if I can help out testing some more stuff

Try to build with XXX_48K_ONLY defined in sbxfi.c.  And try 48kHz
samples (and others).

Also, please show the output of lspci -nv to see the PCI SSID.


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 15 Oct 2008 22:54:18 +0400,
Alexey Bazhin wrote:
> 
> [  376.405480] SBXFI: SET TIMER TICKS = 4096
...
> [  376.490861] SBXFI: IRQ = 0x500

So this is twice as the expected period (4096/96000 = 42ms).
How about the patch below?

diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
index d6b5b34..dbd23ae 100644
--- a/sound/pci/sbxfi/sbxfi.c
+++ b/sound/pci/sbxfi/sbxfi.c
@@ -100,7 +100,7 @@ enum {
 #define SBXFI_PAGE_SIZE		4096
 #define SBXFI_MAX_BUFFER	(SBXFI_TLB_PAGES * SBXFI_PAGE_SIZE)
 #define SBXFI_MAX_SRCS		128	/* 256 / 2 */
-#define SBXFI_TIMER_FREQ	96000
+#define SBXFI_TIMER_FREQ	48000
 /* FIXME: which mask? */
 /* #define SBXFI_DMA_MASK		DMA_32BIT_MASK */
 #define SBXFI_DMA_MASK		DMA_28BIT_MASK


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 15 Oct 2008 22:54:18 +0400,
Alexey Bazhin wrote:
> 
> > > > Does this happen with aplay, too?
> Hm... with aplay I'm getting the same thing as "The Source
> <thesourcehim@gmail.com>" - volume is extremely low and sound is very
> glitchy. And no error as in speakers-test case. Dmesg included in
> attachment.

Which parameters does the WAV file have?
Is it 16bit, 96kHz, 2 channel?

> > I guess it's a timer issue.  Try to define XXX_SYSTEM_TIMER and
> > rebuild (and pull the latest GIT before that, since it had a bug).
> Yep, no error, but sine is still glitchy. Dmesg also included.

Well, I found a fatally silly mistake in the timer update
calculation.  Fixed on git tree and snapshot tarball now.

Give it a try.


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Alexey Bazhin]

On Thu, 16 Oct 2008 12:46:42 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Wed, 15 Oct 2008 22:54:18 +0400,
> Alexey Bazhin wrote:
> > 
> > > > > Does this happen with aplay, too?
> > Hm... with aplay I'm getting the same thing as "The Source
> > <thesourcehim@gmail.com>" - volume is extremely low and sound is
> > very glitchy. And no error as in speakers-test case. Dmesg included
> > in attachment.
> 
> Which parameters does the WAV file have?
> Is it 16bit, 96kHz, 2 channel?
Yes.

-- 
 Alexey Bazhin
  mailto:baz@irc.msk.ru
  ICQ 125125882

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Thu, 16 Oct 2008 15:09:39 +0400,
Alexey Bazhin wrote:
> 
> On Thu, 16 Oct 2008 12:46:42 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Wed, 15 Oct 2008 22:54:18 +0400,
> > Alexey Bazhin wrote:
> > > 
> > > > > > Does this happen with aplay, too?
> > > Hm... with aplay I'm getting the same thing as "The Source
> > > <thesourcehim@gmail.com>" - volume is extremely low and sound is
> > > very glitchy. And no error as in speakers-test case. Dmesg included
> > > in attachment.
> > 
> > Which parameters does the WAV file have?
> > Is it 16bit, 96kHz, 2 channel?
> Yes.

Then this should be handled natively by the driver.
In the case of other formats or other channels, it involves with the
conversion in alsa-lib, and this requires the MMAP mode.

Anyway, further tests with the latest tree are helpful.

thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Jan Wolf]

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 :)

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[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 :)

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

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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=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
> _______________________________________________
> 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

Re: Backported sbxfi driver (UNTESTED!)

[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

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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)

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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!!

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Thu, 16 Oct 2008 19:06:58 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > 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
> >
> >   
> Ok. OpenAL with alsa also seem to cause problems.

In both cases, check the period_size and buffer_size values (shown in
the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
And, try to aplay with these parameters, whether you get the similar
problem.

	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

Just wanted to ask if someone has some good wav files at different
samplerates mono/stereo etc etc [for all cases] (maybe with some voice
instead of the sinus sound I am using.)

Would be nice if we could make our tests based on the same wav files.

Would make it easier to compare the results.

Kind regards
Bjoern

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Bjoern Olausson пишет:
> Just wanted to ask if someone has some good wav files at different
> samplerates mono/stereo etc etc [for all cases] (maybe with some voice
> instead of the sinus sound I am using.)
>
> Would be nice if we could make our tests based on the same wav files.
>
> Would make it easier to compare the results.
>
> Kind regards
> Bjoern
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>   
You can convert wav file to desired format with sox.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Thu, 16 Oct 2008 19:06:58 +0400,
> The Source wrote:
>   
>> Takashi Iwai пишет:
>>     
>>> 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
>>>
>>>   
>>>       
>> Ok. OpenAL with alsa also seem to cause problems.
>>     
>
> In both cases, check the period_size and buffer_size values (shown in
> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> And, try to aplay with these parameters, whether you get the similar
> problem.
>
> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>
>
> Takashi
>
>   
I'm sorry, but any attemp to play file with ossplay results in complete 
system hang with error:
unable to handle NULL ponter dereference at address 
0000000000000008.....(hang, no more output).
I tried many wav formats. So I can't get error log or period and buffer 
sizes, sorry.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

I found a site with a large range of files:
http://bellatrix.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html

aplay plays all files it is capable to decode. No crackel, no noise, just fine.

glass.wav
Signed 16 bit Little Endian, Rate 8000 Hz, Mono

M1F1-int16-AFsp.wav
Signed 16 bit Little Endian, Rate 8000 Hz, Stereo

M1F1-int24-AFsp.wav
Signed 24 bit Little Endian in 3bytes, Rate 8000 Hz, Stereo

M1F1-int32-AFsp.wav
Signed 32 bit Little Endian, Rate 8000 Hz, Stereo

M1F1-uint8-AFsp.wav
Unsigned 8 bit, Rate 8000 Hz, Stereo

stereol.wav
Signed 16 bit Little Endian, Rate 22050 Hz, Stereo

Utopia_Critical_Stop.wav
Signed 16 bit Little Endian, Rate 22050 Hz, Mono

Thought when I try to play the first one with mplayer ---> FREEZZZZZ
Spiele glass.wav.
Audio file-Dateiformat erkannt!
==========================================================================
Öffne Audiodecoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 8000 Hz, 1 ch, s16le, 128.0 kbit/100.00% (ratio: 16000->16000)
Ausgewählter Audiocodec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================

Amarok with backend ALSA plays all files it can decode without problems.

All Signed 16 bit Little Endian, Rate 8000 to 96000 Hz, Stereo do work
(with the same oszilating noise described in my previous post with the
mono files [I just joned two to get stereo])
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Xarteras]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Thu, 16 Oct 2008 22:18:07 +0400,
The Source wrote:
> 
> >> Ok. OpenAL with alsa also seem to cause problems.
> >>     
> >
> > In both cases, check the period_size and buffer_size values (shown in
> > the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> > And, try to aplay with these parameters, whether you get the similar
> > problem.
> >
> > 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >
> >
> > Takashi
> >
> >   
> I'm sorry, but any attemp to play file with ossplay results in complete 
> system hang with error:
> unable to handle NULL ponter dereference at address 
> 0000000000000008.....(hang, no more output).
> I tried many wav formats. So I can't get error log or period and buffer 
> sizes, sorry.

Can anyone confirm to reproduce Oops with OSS apps (ossplay)?

I'm wondering whether this has anything to do with the capture.
Can you record the sound, and change the capture mixer element properly?


thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Thu, 16 Oct 2008 22:07:02 +0200,
Bjoern Olausson wrote:
> 
> I found a site with a large range of files:
> http://bellatrix.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html
> 
> aplay plays all files it is capable to decode. No crackel, no noise, just fine.
> 
> glass.wav
> Signed 16 bit Little Endian, Rate 8000 Hz, Mono
> 
> M1F1-int16-AFsp.wav
> Signed 16 bit Little Endian, Rate 8000 Hz, Stereo
> 
> M1F1-int24-AFsp.wav
> Signed 24 bit Little Endian in 3bytes, Rate 8000 Hz, Stereo
> 
> M1F1-int32-AFsp.wav
> Signed 32 bit Little Endian, Rate 8000 Hz, Stereo
> 
> M1F1-uint8-AFsp.wav
> Unsigned 8 bit, Rate 8000 Hz, Stereo
> 
> stereol.wav
> Signed 16 bit Little Endian, Rate 22050 Hz, Stereo
> 
> Utopia_Critical_Stop.wav
> Signed 16 bit Little Endian, Rate 22050 Hz, Mono
> 
> Thought when I try to play the first one with mplayer ---> FREEZZZZZ
> Spiele glass.wav.
> Audio file-Dateiformat erkannt!
> ==========================================================================
> Öffne Audiodecoder: [pcm] Uncompressed PCM audio decoder
> AUDIO: 8000 Hz, 1 ch, s16le, 128.0 kbit/100.00% (ratio: 16000->16000)
> Ausgewählter Audiocodec: [pcm] afm: pcm (Uncompressed PCM)
> ==========================================================================

Then likely a problem with mplayer.  Can you check which parameters
(period_size, buffer_size) does mplayer use, and try to pass to aplay
via --period-size and --buffer-size options?

> Amarok with backend ALSA plays all files it can decode without problems.
> 
> All Signed 16 bit Little Endian, Rate 8000 to 96000 Hz, Stereo do work
> (with the same oszilating noise described in my previous post with the
> mono files [I just joned two to get stereo])

Hm, mono isn't supported by this hardware, so alsa-lib simply
duplicates the signals to the stereo.  There shouldn't be any
difference in that manner...


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Thu, 16 Oct 2008 22:18:07 +0400,
> The Source wrote:
>   
>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>     
>>>>         
>>> In both cases, check the period_size and buffer_size values (shown in
>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>> And, try to aplay with these parameters, whether you get the similar
>>> problem.
>>>
>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>
>>>
>>> Takashi
>>>
>>>   
>>>       
>> I'm sorry, but any attemp to play file with ossplay results in complete 
>> system hang with error:
>> unable to handle NULL ponter dereference at address 
>> 0000000000000008.....(hang, no more output).
>> I tried many wav formats. So I can't get error log or period and buffer 
>> sizes, sorry.
>>     
>
> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>
> I'm wondering whether this has anything to do with the capture.
> Can you record the sound, and change the capture mixer element properly?
>
>
> thanks,
>
> Takashi
>
>   
Err, I'm not sure I understand. Could you please explain step-by-step?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Fri, 17 Oct 2008 10:26:27 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Thu, 16 Oct 2008 22:18:07 +0400,
> > The Source wrote:
> >   
> >>>> Ok. OpenAL with alsa also seem to cause problems.
> >>>>     
> >>>>         
> >>> In both cases, check the period_size and buffer_size values (shown in
> >>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> >>> And, try to aplay with these parameters, whether you get the similar
> >>> problem.
> >>>
> >>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >>>
> >>>
> >>> Takashi
> >>>
> >>>   
> >>>       
> >> I'm sorry, but any attemp to play file with ossplay results in complete 
> >> system hang with error:
> >> unable to handle NULL ponter dereference at address 
> >> 0000000000000008.....(hang, no more output).
> >> I tried many wav formats. So I can't get error log or period and buffer 
> >> sizes, sorry.
> >>     
> >
> > Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> >
> > I'm wondering whether this has anything to do with the capture.
> > Can you record the sound, and change the capture mixer element properly?
> >
> >
> > thanks,
> >
> > Takashi
> >
> >   
> Err, I'm not sure I understand. Could you please explain step-by-step?

Just run arecord to record something.  And, change the recording
source via mixer.

So far, I got little report about recording, and I'm not sure whether
it works at all.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Fri, 17 Oct 2008 10:26:27 +0400,
> The Source wrote:
>   
>> Takashi Iwai пишет:
>>     
>>> At Thu, 16 Oct 2008 22:18:07 +0400,
>>> The Source wrote:
>>>   
>>>       
>>>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> In both cases, check the period_size and buffer_size values (shown in
>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>>>> And, try to aplay with these parameters, whether you get the similar
>>>>> problem.
>>>>>
>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>>>
>>>>>
>>>>> Takashi
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
>>>> system hang with error:
>>>> unable to handle NULL ponter dereference at address 
>>>> 0000000000000008.....(hang, no more output).
>>>> I tried many wav formats. So I can't get error log or period and buffer 
>>>> sizes, sorry.
>>>>     
>>>>         
>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>>>
>>> I'm wondering whether this has anything to do with the capture.
>>> Can you record the sound, and change the capture mixer element properly?
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>
>>>   
>>>       
>> Err, I'm not sure I understand. Could you please explain step-by-step?
>>     
>
> Just run arecord to record something.  And, change the recording
> source via mixer.
>
> So far, I got little report about recording, and I'm not sure whether
> it works at all.
>
>
> Takashi
>
>   
Should I change source WHILE recording or AFTER recording? Should I 
change it to OSS or just to another ALSA source?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Thu, 16 Oct 2008 22:18:07 +0400,
> The Source wrote:
>   
>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>     
>>>>         
>>> In both cases, check the period_size and buffer_size values (shown in
>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>> And, try to aplay with these parameters, whether you get the similar
>>> problem.
>>>
>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>
>>>
>>> Takashi
>>>
>>>   
>>>       
>> I'm sorry, but any attemp to play file with ossplay results in complete 
>> system hang with error:
>> unable to handle NULL ponter dereference at address 
>> 0000000000000008.....(hang, no more output).
>> I tried many wav formats. So I can't get error log or period and buffer 
>> sizes, sorry.
>>     
>
> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>
> I'm wondering whether this has anything to do with the capture.
> Can you record the sound, and change the capture mixer element properly?
>
>
> thanks,
>
> Takashi
>
>   
I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
buffer size (default). Sound is choppy (sound pauses is more frequent 
when rate is lower).
However an attempt to play the same file with the same period and buffer 
sizes with aplay results in complete system hang.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Fri, 17 Oct 2008 10:26:27 +0400,
> The Source wrote:
>   
>> Takashi Iwai пишет:
>>     
>>> At Thu, 16 Oct 2008 22:18:07 +0400,
>>> The Source wrote:
>>>   
>>>       
>>>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> In both cases, check the period_size and buffer_size values (shown in
>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>>>> And, try to aplay with these parameters, whether you get the similar
>>>>> problem.
>>>>>
>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>>>
>>>>>
>>>>> Takashi
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
>>>> system hang with error:
>>>> unable to handle NULL ponter dereference at address 
>>>> 0000000000000008.....(hang, no more output).
>>>> I tried many wav formats. So I can't get error log or period and buffer 
>>>> sizes, sorry.
>>>>     
>>>>         
>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>>>
>>> I'm wondering whether this has anything to do with the capture.
>>> Can you record the sound, and change the capture mixer element properly?
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>
>>>   
>>>       
>> Err, I'm not sure I understand. Could you please explain step-by-step?
>>     
>
> Just run arecord to record something.  And, change the recording
> source via mixer.
>
> So far, I got little report about recording, and I'm not sure whether
> it works at all.
>
>
> Takashi
>
>   
I tried arecord with several sources and formats. I don't have mic or 
other recording device so the file is silent (and only 1 second length, 
I terminated arecord after 5 or so seconds, I don't know is 1s length is 
ok or not in this case), but at least it doesn't crash. Using ossrecord 
leads to NULL pointer dereference at 0000000000000008 and hang.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Xarteras]

Takashi Iwai wrote:
> At Fri, 17 Oct 2008 10:26:27 +0400,
> The Source wrote:
>> Takashi Iwai пишет:
>>> At Thu, 16 Oct 2008 22:18:07 +0400,
>>> The Source wrote:
>>>   
>>>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>>>     
>>>>>>         
>>>>> In both cases, check the period_size and buffer_size values (shown in
>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>>>> And, try to aplay with these parameters, whether you get the similar
>>>>> problem.
>>>>>
>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>>>
>>>>>
>>>>> Takashi
>>>>>
>>>>>   
>>>>>       
>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
>>>> system hang with error:
>>>> unable to handle NULL ponter dereference at address 
>>>> 0000000000000008.....(hang, no more output).
>>>> I tried many wav formats. So I can't get error log or period and buffer 
>>>> sizes, sorry.
>>>>     
>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>>>
>>> I'm wondering whether this has anything to do with the capture.
>>> Can you record the sound, and change the capture mixer element properly?
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>
>>>   
>> Err, I'm not sure I understand. Could you please explain step-by-step?
> 
> Just run arecord to record something.  And, change the recording
> source via mixer.
> 
> So far, I got little report about recording, and I'm not sure whether
> it works at all.

I just tested ossplay and arecord.
For me both result in a spontanous crash back to BIOS without leaving 
any traces in the log files.
Everything else works fine so far.

Jan Wolf
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Xarteras пишет:
> Takashi Iwai wrote:
>> At Fri, 17 Oct 2008 10:26:27 +0400,
>> The Source wrote:
>>> Takashi Iwai пишет:
>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
>>>> The Source wrote:
>>>>  
>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>>>>             
>>>>>> In both cases, check the period_size and buffer_size values 
>>>>>> (shown in
>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>>>>> And, try to aplay with these parameters, whether you get the similar
>>>>>> problem.
>>>>>>
>>>>>>     % aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>>>>
>>>>>>
>>>>>> Takashi
>>>>>>
>>>>>>         
>>>>> I'm sorry, but any attemp to play file with ossplay results in 
>>>>> complete system hang with error:
>>>>> unable to handle NULL ponter dereference at address 
>>>>> 0000000000000008.....(hang, no more output).
>>>>> I tried many wav formats. So I can't get error log or period and 
>>>>> buffer sizes, sorry.
>>>>>     
>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>>>>
>>>> I'm wondering whether this has anything to do with the capture.
>>>> Can you record the sound, and change the capture mixer element 
>>>> properly?
>>>>
>>>>
>>>> thanks,
>>>>
>>>> Takashi
>>>>
>>>>   
>>> Err, I'm not sure I understand. Could you please explain step-by-step?
>>
>> Just run arecord to record something.  And, change the recording
>> source via mixer.
>>
>> So far, I got little report about recording, and I'm not sure whether
>> it works at all.
>
> I just tested ossplay and arecord.
> For me both result in a spontanous crash back to BIOS without leaving 
> any traces in the log files.
> Everything else works fine so far.
>
> Jan Wolf
>
Seems that only one application at a time can use alsa. All other apps 
say they can't initialize sound until I close the first app.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Fri, 17 Oct 2008 09:00:30 +0000,
Xarteras wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 17 Oct 2008 10:26:27 +0400,
> > The Source wrote:
> >> Takashi Iwai пишет:
> >>> At Thu, 16 Oct 2008 22:18:07 +0400,
> >>> The Source wrote:
> >>>   
> >>>>>> Ok. OpenAL with alsa also seem to cause problems.
> >>>>>>     
> >>>>>>         
> >>>>> In both cases, check the period_size and buffer_size values (shown in
> >>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> >>>>> And, try to aplay with these parameters, whether you get the similar
> >>>>> problem.
> >>>>>
> >>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >>>>>
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>>   
> >>>>>       
> >>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> >>>> system hang with error:
> >>>> unable to handle NULL ponter dereference at address 
> >>>> 0000000000000008.....(hang, no more output).
> >>>> I tried many wav formats. So I can't get error log or period and buffer 
> >>>> sizes, sorry.
> >>>>     
> >>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> >>>
> >>> I'm wondering whether this has anything to do with the capture.
> >>> Can you record the sound, and change the capture mixer element properly?
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>>   
> >> Err, I'm not sure I understand. Could you please explain step-by-step?
> > 
> > Just run arecord to record something.  And, change the recording
> > source via mixer.
> > 
> > So far, I got little report about recording, and I'm not sure whether
> > it works at all.
> 
> I just tested ossplay and arecord.
> For me both result in a spontanous crash back to BIOS without leaving 
> any traces in the log files.
> Everything else works fine so far.

OK, then the problem is consistent.
It's a bit tough to check without a proper log.
How about running with strace?  What is the last syscall before the
dead end?


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Fri, 17 Oct 2008 13:17:28 +0400,
The Source wrote:
> 
> Xarteras пишет:
> > Takashi Iwai wrote:
> >> At Fri, 17 Oct 2008 10:26:27 +0400,
> >> The Source wrote:
> >>> Takashi Iwai пишет:
> >>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> >>>> The Source wrote:
> >>>>  
> >>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> >>>>>>>             
> >>>>>> In both cases, check the period_size and buffer_size values 
> >>>>>> (shown in
> >>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> >>>>>> And, try to aplay with these parameters, whether you get the similar
> >>>>>> problem.
> >>>>>>
> >>>>>>     % aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >>>>>>
> >>>>>>
> >>>>>> Takashi
> >>>>>>
> >>>>>>         
> >>>>> I'm sorry, but any attemp to play file with ossplay results in 
> >>>>> complete system hang with error:
> >>>>> unable to handle NULL ponter dereference at address 
> >>>>> 0000000000000008.....(hang, no more output).
> >>>>> I tried many wav formats. So I can't get error log or period and 
> >>>>> buffer sizes, sorry.
> >>>>>     
> >>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> >>>>
> >>>> I'm wondering whether this has anything to do with the capture.
> >>>> Can you record the sound, and change the capture mixer element 
> >>>> properly?
> >>>>
> >>>>
> >>>> thanks,
> >>>>
> >>>> Takashi
> >>>>
> >>>>   
> >>> Err, I'm not sure I understand. Could you please explain step-by-step?
> >>
> >> Just run arecord to record something.  And, change the recording
> >> source via mixer.
> >>
> >> So far, I got little report about recording, and I'm not sure whether
> >> it works at all.
> >
> > I just tested ossplay and arecord.
> > For me both result in a spontanous crash back to BIOS without leaving 
> > any traces in the log files.
> > Everything else works fine so far.
> >
> > Jan Wolf
> >
> Seems that only one application at a time can use alsa. All other apps 
> say they can't initialize sound until I close the first app.

Yes, it's a design, so far.
Right now, DSP is bypassed and the SRC is directly connected (as far
as I understood from the code).  So, I guess multi-playing won't work
without DSP codes.

You can use dmix instead.  At least, there is one positive report :)
For testing, just run like
	% aplay -Dplug:dmix foo.wav
   

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Fri, 17 Oct 2008 11:57:08 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Thu, 16 Oct 2008 22:18:07 +0400,
> > The Source wrote:
> >   
> >>>> Ok. OpenAL with alsa also seem to cause problems.
> >>>>     
> >>>>         
> >>> In both cases, check the period_size and buffer_size values (shown in
> >>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> >>> And, try to aplay with these parameters, whether you get the similar
> >>> problem.
> >>>
> >>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >>>
> >>>
> >>> Takashi
> >>>
> >>>   
> >>>       
> >> I'm sorry, but any attemp to play file with ossplay results in complete 
> >> system hang with error:
> >> unable to handle NULL ponter dereference at address 
> >> 0000000000000008.....(hang, no more output).
> >> I tried many wav formats. So I can't get error log or period and buffer 
> >> sizes, sorry.
> >>     
> >
> > Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> >
> > I'm wondering whether this has anything to do with the capture.
> > Can you record the sound, and change the capture mixer element properly?
> >
> >
> > thanks,
> >
> > Takashi
> >
> >   
> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> buffer size (default). Sound is choppy (sound pauses is more frequent 
> when rate is lower).
> However an attempt to play the same file with the same period and buffer 
> sizes with aplay results in complete system hang.

OK, that looks like a problem.  Looks like the timer resolution can be
short like that, or something racy in the timer handling.

Can you check whether this happens with XXX_SYSTEM_TIMER, too?

Or, does the patch below avoid the problem, at least?


thanks,

Takashi

diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
index 26a6cd3..5ceb228 100644
--- a/sound/pci/sbxfi/sbxfi.c
+++ b/sound/pci/sbxfi/sbxfi.c
@@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
 #else
 
 #define MAX_TICKS	((1 << 13) - 1)
+#define MIN_TICKS	1000		/* FIXME: really so? */
 
 static void sbxfi_init_timer(struct sbxfi *chip)
 {
@@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
 	LOG(2, "SET TIMER TICKS = %d\n", ticks);
 	if (ticks > MAX_TICKS)
 		ticks = MAX_TICKS;
+	else if (ticks < MIN_TICKS)
+		ticks = MIN_TICKS;
 	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
 }
 static void sbxfi_stop_timer(struct sbxfi *chip)
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Xarteras]

Takashi Iwai wrote:
> At Fri, 17 Oct 2008 09:00:30 +0000,
> Xarteras wrote:
>> Takashi Iwai wrote:
>>> At Fri, 17 Oct 2008 10:26:27 +0400,
>>> The Source wrote:
>>>> Takashi Iwai пишет:
>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
>>>>> The Source wrote:
>>>>>   
>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>>>>>     
>>>>>>>>         
>>>>>>> In both cases, check the period_size and buffer_size values (shown in
>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>>>>>> And, try to aplay with these parameters, whether you get the similar
>>>>>>> problem.
>>>>>>>
>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>>>>>
>>>>>>>
>>>>>>> Takashi
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
>>>>>> system hang with error:
>>>>>> unable to handle NULL ponter dereference at address 
>>>>>> 0000000000000008.....(hang, no more output).
>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
>>>>>> sizes, sorry.
>>>>>>     
>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>>>>>
>>>>> I'm wondering whether this has anything to do with the capture.
>>>>> Can you record the sound, and change the capture mixer element properly?
>>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Takashi
>>>>>
>>>>>   
>>>> Err, I'm not sure I understand. Could you please explain step-by-step?
>>> Just run arecord to record something.  And, change the recording
>>> source via mixer.
>>>
>>> So far, I got little report about recording, and I'm not sure whether
>>> it works at all.
>> I just tested ossplay and arecord.
>> For me both result in a spontanous crash back to BIOS without leaving 
>> any traces in the log files.
>> Everything else works fine so far.
> 
> OK, then the problem is consistent.
> It's a bit tough to check without a proper log.
> How about running with strace?  What is the last syscall before the
> dead end?

I just noticed I still had a dsnoop/dmix set up and renamed asound.conf 
for retesting.
Now at least arecord doesn't crash the system anymore, but it only 
returns silence (Despite a mic being connected).

ossplay still crashes though and strace isn't of much use.
Running ossplay causes a sys reset so fast the strace output cannot even 
be flushed to disk anymore, neverless be up long enough to read it on 
the screen.

Jan Wolf
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Fri, 17 Oct 2008 11:57:08 +0400,
> The Source wrote:
>   
>> Takashi Iwai пишет:
>>     
>>> At Thu, 16 Oct 2008 22:18:07 +0400,
>>> The Source wrote:
>>>   
>>>       
>>>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> In both cases, check the period_size and buffer_size values (shown in
>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>>>> And, try to aplay with these parameters, whether you get the similar
>>>>> problem.
>>>>>
>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>>>
>>>>>
>>>>> Takashi
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
>>>> system hang with error:
>>>> unable to handle NULL ponter dereference at address 
>>>> 0000000000000008.....(hang, no more output).
>>>> I tried many wav formats. So I can't get error log or period and buffer 
>>>> sizes, sorry.
>>>>     
>>>>         
>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>>>
>>> I'm wondering whether this has anything to do with the capture.
>>> Can you record the sound, and change the capture mixer element properly?
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>
>>>   
>>>       
>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
>> buffer size (default). Sound is choppy (sound pauses is more frequent 
>> when rate is lower).
>> However an attempt to play the same file with the same period and buffer 
>> sizes with aplay results in complete system hang.
>>     
>
> OK, that looks like a problem.  Looks like the timer resolution can be
> short like that, or something racy in the timer handling.
>
> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
>
> Or, does the patch below avoid the problem, at least?
>
>
> thanks,
>
> Takashi
>
> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> index 26a6cd3..5ceb228 100644
> --- a/sound/pci/sbxfi/sbxfi.c
> +++ b/sound/pci/sbxfi/sbxfi.c
> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
>  #else
>  
>  #define MAX_TICKS	((1 << 13) - 1)
> +#define MIN_TICKS	1000		/* FIXME: really so? */
>  
>  static void sbxfi_init_timer(struct sbxfi *chip)
>  {
> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
>  	if (ticks > MAX_TICKS)
>  		ticks = MAX_TICKS;
> +	else if (ticks < MIN_TICKS)
> +		ticks = MIN_TICKS;
>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
>  }
>  static void sbxfi_stop_timer(struct sbxfi *chip)
>
>   
After patch:

Without system timer:

aplay --period-size=1024 96000_16_Stereo.wav
Plays fine

aplay --period-size=1024 22050_16_Mono.wav
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
Hang

With system timer:

aplay --period-size=1024 96000_16_Stereo.wav
Superglitch. Each sample is played many times before advancing to next one.

aplay --period-size=1024 22050_16_Mono.wav
Instant reboot.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Fri, 17 Oct 2008 13:58:20 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Fri, 17 Oct 2008 11:57:08 +0400,
> > The Source wrote:
> >   
> >> Takashi Iwai пишет:
> >>     
> >>> At Thu, 16 Oct 2008 22:18:07 +0400,
> >>> The Source wrote:
> >>>   
> >>>       
> >>>>>> Ok. OpenAL with alsa also seem to cause problems.
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> In both cases, check the period_size and buffer_size values (shown in
> >>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> >>>>> And, try to aplay with these parameters, whether you get the similar
> >>>>> problem.
> >>>>>
> >>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >>>>>
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> >>>> system hang with error:
> >>>> unable to handle NULL ponter dereference at address 
> >>>> 0000000000000008.....(hang, no more output).
> >>>> I tried many wav formats. So I can't get error log or period and buffer 
> >>>> sizes, sorry.
> >>>>     
> >>>>         
> >>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> >>>
> >>> I'm wondering whether this has anything to do with the capture.
> >>> Can you record the sound, and change the capture mixer element properly?
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>>   
> >>>       
> >> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> >> buffer size (default). Sound is choppy (sound pauses is more frequent 
> >> when rate is lower).
> >> However an attempt to play the same file with the same period and buffer 
> >> sizes with aplay results in complete system hang.
> >>     
> >
> > OK, that looks like a problem.  Looks like the timer resolution can be
> > short like that, or something racy in the timer handling.
> >
> > Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> >
> > Or, does the patch below avoid the problem, at least?
> >
> >
> > thanks,
> >
> > Takashi
> >
> > diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > index 26a6cd3..5ceb228 100644
> > --- a/sound/pci/sbxfi/sbxfi.c
> > +++ b/sound/pci/sbxfi/sbxfi.c
> > @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> >  #else
> >  
> >  #define MAX_TICKS	((1 << 13) - 1)
> > +#define MIN_TICKS	1000		/* FIXME: really so? */
> >  
> >  static void sbxfi_init_timer(struct sbxfi *chip)
> >  {
> > @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> >  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> >  	if (ticks > MAX_TICKS)
> >  		ticks = MAX_TICKS;
> > +	else if (ticks < MIN_TICKS)
> > +		ticks = MIN_TICKS;
> >  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> >  }
> >  static void sbxfi_stop_timer(struct sbxfi *chip)
> >
> >   
> After patch:
> 
> Without system timer:
> 
> aplay --period-size=1024 96000_16_Stereo.wav
> Plays fine
> 
> aplay --period-size=1024 22050_16_Mono.wav
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> Hang
> 
> With system timer:
> 
> aplay --period-size=1024 96000_16_Stereo.wav
> Superglitch. Each sample is played many times before advancing to next one.
> 
> aplay --period-size=1024 22050_16_Mono.wav
> Instant reboot.

Just to be sure: you don't enable XXX_CONT_RATE, right?
It's known to be buggy, so disabled as default now.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Tony Vroon]

[-- Attachment #1.1: Type: text/plain, Size: 387 bytes --]

On Fri, 2008-10-17 at 09:50 +0000, Xarteras wrote:
> ossplay still crashes though and strace isn't of much use.
> Running ossplay causes a sys reset so fast the strace output cannot even 
> be flushed to disk anymore, neverless be up long enough to read it on 
> the screen.

A serial console may help you there, assuming you have two machines.

> Jan Wolf

Regards,
Tony V.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Takashi Iwai пишет:
> At Fri, 17 Oct 2008 13:58:20 +0400,
> The Source wrote:
>   
>> Takashi Iwai пишет:
>>     
>>> At Fri, 17 Oct 2008 11:57:08 +0400,
>>> The Source wrote:
>>>   
>>>       
>>>> Takashi Iwai пишет:
>>>>     
>>>>         
>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
>>>>> The Source wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> In both cases, check the period_size and buffer_size values (shown in
>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>>>>>> And, try to aplay with these parameters, whether you get the similar
>>>>>>> problem.
>>>>>>>
>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>>>>>
>>>>>>>
>>>>>>> Takashi
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
>>>>>> system hang with error:
>>>>>> unable to handle NULL ponter dereference at address 
>>>>>> 0000000000000008.....(hang, no more output).
>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
>>>>>> sizes, sorry.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>>>>>
>>>>> I'm wondering whether this has anything to do with the capture.
>>>>> Can you record the sound, and change the capture mixer element properly?
>>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Takashi
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
>>>> when rate is lower).
>>>> However an attempt to play the same file with the same period and buffer 
>>>> sizes with aplay results in complete system hang.
>>>>     
>>>>         
>>> OK, that looks like a problem.  Looks like the timer resolution can be
>>> short like that, or something racy in the timer handling.
>>>
>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
>>>
>>> Or, does the patch below avoid the problem, at least?
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>
>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
>>> index 26a6cd3..5ceb228 100644
>>> --- a/sound/pci/sbxfi/sbxfi.c
>>> +++ b/sound/pci/sbxfi/sbxfi.c
>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
>>>  #else
>>>  
>>>  #define MAX_TICKS	((1 << 13) - 1)
>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
>>>  
>>>  static void sbxfi_init_timer(struct sbxfi *chip)
>>>  {
>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
>>>  	if (ticks > MAX_TICKS)
>>>  		ticks = MAX_TICKS;
>>> +	else if (ticks < MIN_TICKS)
>>> +		ticks = MIN_TICKS;
>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
>>>  }
>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
>>>
>>>   
>>>       
>> After patch:
>>
>> Without system timer:
>>
>> aplay --period-size=1024 96000_16_Stereo.wav
>> Plays fine
>>
>> aplay --period-size=1024 22050_16_Mono.wav
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
>> Hang
>>
>> With system timer:
>>
>> aplay --period-size=1024 96000_16_Stereo.wav
>> Superglitch. Each sample is played many times before advancing to next one.
>>
>> aplay --period-size=1024 22050_16_Mono.wav
>> Instant reboot.
>>     
>
> Just to be sure: you don't enable XXX_CONT_RATE, right?
> It's known to be buggy, so disabled as default now.
>
>
> Takashi
>
>   
It is disabled for me too.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Fri, 17 Oct 2008 14:01:55 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Fri, 17 Oct 2008 13:58:20 +0400,
> > The Source wrote:
> >   
> >> Takashi Iwai пишет:
> >>     
> >>> At Fri, 17 Oct 2008 11:57:08 +0400,
> >>> The Source wrote:
> >>>   
> >>>       
> >>>> Takashi Iwai пишет:
> >>>>     
> >>>>         
> >>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> >>>>> The Source wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> >>>>>>>>     
> >>>>>>>>         
> >>>>>>>>             
> >>>>>>>>                 
> >>>>>>> In both cases, check the period_size and buffer_size values (shown in
> >>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> >>>>>>> And, try to aplay with these parameters, whether you get the similar
> >>>>>>> problem.
> >>>>>>>
> >>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >>>>>>>
> >>>>>>>
> >>>>>>> Takashi
> >>>>>>>
> >>>>>>>   
> >>>>>>>       
> >>>>>>>           
> >>>>>>>               
> >>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> >>>>>> system hang with error:
> >>>>>> unable to handle NULL ponter dereference at address 
> >>>>>> 0000000000000008.....(hang, no more output).
> >>>>>> I tried many wav formats. So I can't get error log or period and buffer 
> >>>>>> sizes, sorry.
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> >>>>>
> >>>>> I'm wondering whether this has anything to do with the capture.
> >>>>> Can you record the sound, and change the capture mixer element properly?
> >>>>>
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> >>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
> >>>> when rate is lower).
> >>>> However an attempt to play the same file with the same period and buffer 
> >>>> sizes with aplay results in complete system hang.
> >>>>     
> >>>>         
> >>> OK, that looks like a problem.  Looks like the timer resolution can be
> >>> short like that, or something racy in the timer handling.
> >>>
> >>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> >>>
> >>> Or, does the patch below avoid the problem, at least?
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> >>> index 26a6cd3..5ceb228 100644
> >>> --- a/sound/pci/sbxfi/sbxfi.c
> >>> +++ b/sound/pci/sbxfi/sbxfi.c
> >>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> >>>  #else
> >>>  
> >>>  #define MAX_TICKS	((1 << 13) - 1)
> >>> +#define MIN_TICKS	1000		/* FIXME: really so? */
> >>>  
> >>>  static void sbxfi_init_timer(struct sbxfi *chip)
> >>>  {
> >>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> >>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> >>>  	if (ticks > MAX_TICKS)
> >>>  		ticks = MAX_TICKS;
> >>> +	else if (ticks < MIN_TICKS)
> >>> +		ticks = MIN_TICKS;
> >>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> >>>  }
> >>>  static void sbxfi_stop_timer(struct sbxfi *chip)
> >>>
> >>>   
> >>>       
> >> After patch:
> >>
> >> Without system timer:
> >>
> >> aplay --period-size=1024 96000_16_Stereo.wav
> >> Plays fine
> >>
> >> aplay --period-size=1024 22050_16_Mono.wav
> >> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> >> Hang
> >>
> >> With system timer:
> >>
> >> aplay --period-size=1024 96000_16_Stereo.wav
> >> Superglitch. Each sample is played many times before advancing to next one.
> >>
> >> aplay --period-size=1024 22050_16_Mono.wav
> >> Instant reboot.
> >>     
> >
> > Just to be sure: you don't enable XXX_CONT_RATE, right?
> > It's known to be buggy, so disabled as default now.
> >
> >
> > Takashi
> >
> >   
> It is disabled for me too.

And the patch didn't help?


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Fri, 17 Oct 2008 14:16:38 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Fri, 17 Oct 2008 14:01:55 +0400,
> > The Source wrote:
> >   
> >> Takashi Iwai пишет:
> >>     
> >>> At Fri, 17 Oct 2008 13:58:20 +0400,
> >>> The Source wrote:
> >>>   
> >>>       
> >>>> Takashi Iwai пишет:
> >>>>     
> >>>>         
> >>>>> At Fri, 17 Oct 2008 11:57:08 +0400,
> >>>>> The Source wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> Takashi Iwai пишет:
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> >>>>>>> The Source wrote:
> >>>>>>>   
> >>>>>>>       
> >>>>>>>           
> >>>>>>>               
> >>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> >>>>>>>>>>     
> >>>>>>>>>>         
> >>>>>>>>>>             
> >>>>>>>>>>                 
> >>>>>>>>>>                     
> >>>>>>>>> In both cases, check the period_size and buffer_size values (shown in
> >>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> >>>>>>>>> And, try to aplay with these parameters, whether you get the similar
> >>>>>>>>> problem.
> >>>>>>>>>
> >>>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Takashi
> >>>>>>>>>
> >>>>>>>>>   
> >>>>>>>>>       
> >>>>>>>>>           
> >>>>>>>>>               
> >>>>>>>>>                   
> >>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> >>>>>>>> system hang with error:
> >>>>>>>> unable to handle NULL ponter dereference at address 
> >>>>>>>> 0000000000000008.....(hang, no more output).
> >>>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
> >>>>>>>> sizes, sorry.
> >>>>>>>>     
> >>>>>>>>         
> >>>>>>>>             
> >>>>>>>>                 
> >>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> >>>>>>>
> >>>>>>> I'm wondering whether this has anything to do with the capture.
> >>>>>>> Can you record the sound, and change the capture mixer element properly?
> >>>>>>>
> >>>>>>>
> >>>>>>> thanks,
> >>>>>>>
> >>>>>>> Takashi
> >>>>>>>
> >>>>>>>   
> >>>>>>>       
> >>>>>>>           
> >>>>>>>               
> >>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> >>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
> >>>>>> when rate is lower).
> >>>>>> However an attempt to play the same file with the same period and buffer 
> >>>>>> sizes with aplay results in complete system hang.
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> OK, that looks like a problem.  Looks like the timer resolution can be
> >>>>> short like that, or something racy in the timer handling.
> >>>>>
> >>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> >>>>>
> >>>>> Or, does the patch below avoid the problem, at least?
> >>>>>
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> >>>>> index 26a6cd3..5ceb228 100644
> >>>>> --- a/sound/pci/sbxfi/sbxfi.c
> >>>>> +++ b/sound/pci/sbxfi/sbxfi.c
> >>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> >>>>>  #else
> >>>>>  
> >>>>>  #define MAX_TICKS	((1 << 13) - 1)
> >>>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
> >>>>>  
> >>>>>  static void sbxfi_init_timer(struct sbxfi *chip)
> >>>>>  {
> >>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> >>>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> >>>>>  	if (ticks > MAX_TICKS)
> >>>>>  		ticks = MAX_TICKS;
> >>>>> +	else if (ticks < MIN_TICKS)
> >>>>> +		ticks = MIN_TICKS;
> >>>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> >>>>>  }
> >>>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> After patch:
> >>>>
> >>>> Without system timer:
> >>>>
> >>>> aplay --period-size=1024 96000_16_Stereo.wav
> >>>> Plays fine
> >>>>
> >>>> aplay --period-size=1024 22050_16_Mono.wav
> >>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> >>>> Hang
> >>>>
> >>>> With system timer:
> >>>>
> >>>> aplay --period-size=1024 96000_16_Stereo.wav
> >>>> Superglitch. Each sample is played many times before advancing to next one.
> >>>>
> >>>> aplay --period-size=1024 22050_16_Mono.wav
> >>>> Instant reboot.
> >>>>     
> >>>>         
> >>> Just to be sure: you don't enable XXX_CONT_RATE, right?
> >>> It's known to be buggy, so disabled as default now.
> >>>
> >>>
> >>> Takashi
> >>>
> >>>   
> >>>       
> >> It is disabled for me too.
> >>     
> >
> > And the patch didn't help?
> >
> >
> > Takashi
> >
> >   
> Only 96000Hz Stereo without system timer plays fine after patch.

Please elaborate?  You mean 22.5k still doesn't work with the patch?
Does 22.5kHz ever work with other parameters?  It'd be really helpful
if you get the full Oops log...

The patch affects only the emu20k1 timer.  The system timer stuff
isn't touched by it.

The reboot implies that it's unlikely the timer but the driver wrote
something wrong (unless you have the set up that the kernel traps and
automatically reboot).  But, it's nothing but a wild guess at this
point.

Anyway, I updated the driver code a bit again.  Please check the
latest one.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Xarteras]

Tony Vroon wrote:
> On Fri, 2008-10-17 at 09:50 +0000, Xarteras wrote:
>> ossplay still crashes though and strace isn't of much use.
>> Running ossplay causes a sys reset so fast the strace output cannot even 
>> be flushed to disk anymore, neverless be up long enough to read it on 
>> the screen.
> 
> A serial console may help you there, assuming you have two machines.

Good idea :)

Just tried it, but even a 115200 baud serial connection isn't fast 
enough to give me more than the first three lines of useless strace 
output before it's back to BIOS.

Jan Wolf

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

On Fri, Oct 17, 2008 at 12:35 PM, Xarteras
<xarteras@nostalgicnetworxx.org> wrote:
> Tony Vroon wrote:
>> On Fri, 2008-10-17 at 09:50 +0000, Xarteras wrote:
>>> ossplay still crashes though and strace isn't of much use.
>>> Running ossplay causes a sys reset so fast the strace output cannot even
>>> be flushed to disk anymore, neverless be up long enough to read it on
>>> the screen.
>>
>> A serial console may help you there, assuming you have two machines.
>
> Good idea :)
>
> Just tried it, but even a 115200 baud serial connection isn't fast
> enough to give me more than the first three lines of useless strace
> output before it's back to BIOS.
>
> Jan Wolf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Same here, not with serial, not with ssh, not even with a Camera
recording the screen....

No logs either...

By the way,
-amarok with xine as backand using ALSA works
-Flash movies with sound in Opera work
-Xine works flawless (nice sound)...just watched "Big_bug_bunny_080p stereo.ogg"

Now I am listening to my favourite song Diana_Krall_-_Black_Crow.mp3
(256kbps 44100Hz) with xine.
Clear, distortionfree, lovely sound!

Re: Backported sbxfi driver (UNTESTED!)

[James Courtier-Dutton]

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.

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 6344 bytes --]

On Fri, 2008-10-17 at 12:27 +0200, Takashi Iwai wrote:
> At Fri, 17 Oct 2008 14:16:38 +0400,
> The Source wrote:
> > 
> > Takashi Iwai пишет:
> > > At Fri, 17 Oct 2008 14:01:55 +0400,
> > > The Source wrote:
> > >   
> > >> Takashi Iwai пишет:
> > >>     
> > >>> At Fri, 17 Oct 2008 13:58:20 +0400,
> > >>> The Source wrote:
> > >>>   
> > >>>       
> > >>>> Takashi Iwai пишет:
> > >>>>     
> > >>>>         
> > >>>>> At Fri, 17 Oct 2008 11:57:08 +0400,
> > >>>>> The Source wrote:
> > >>>>>   
> > >>>>>       
> > >>>>>           
> > >>>>>> Takashi Iwai пишет:
> > >>>>>>     
> > >>>>>>         
> > >>>>>>             
> > >>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> > >>>>>>> The Source wrote:
> > >>>>>>>   
> > >>>>>>>       
> > >>>>>>>           
> > >>>>>>>               
> > >>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> > >>>>>>>>>>     
> > >>>>>>>>>>         
> > >>>>>>>>>>             
> > >>>>>>>>>>                 
> > >>>>>>>>>>                     
> > >>>>>>>>> In both cases, check the period_size and buffer_size values (shown in
> > >>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> > >>>>>>>>> And, try to aplay with these parameters, whether you get the similar
> > >>>>>>>>> problem.
> > >>>>>>>>>
> > >>>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Takashi
> > >>>>>>>>>
> > >>>>>>>>>   
> > >>>>>>>>>       
> > >>>>>>>>>           
> > >>>>>>>>>               
> > >>>>>>>>>                   
> > >>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> > >>>>>>>> system hang with error:
> > >>>>>>>> unable to handle NULL ponter dereference at address 
> > >>>>>>>> 0000000000000008.....(hang, no more output).
> > >>>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
> > >>>>>>>> sizes, sorry.
> > >>>>>>>>     
> > >>>>>>>>         
> > >>>>>>>>             
> > >>>>>>>>                 
> > >>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> > >>>>>>>
> > >>>>>>> I'm wondering whether this has anything to do with the capture.
> > >>>>>>> Can you record the sound, and change the capture mixer element properly?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> thanks,
> > >>>>>>>
> > >>>>>>> Takashi
> > >>>>>>>
> > >>>>>>>   
> > >>>>>>>       
> > >>>>>>>           
> > >>>>>>>               
> > >>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> > >>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
> > >>>>>> when rate is lower).
> > >>>>>> However an attempt to play the same file with the same period and buffer 
> > >>>>>> sizes with aplay results in complete system hang.
> > >>>>>>     
> > >>>>>>         
> > >>>>>>             
> > >>>>> OK, that looks like a problem.  Looks like the timer resolution can be
> > >>>>> short like that, or something racy in the timer handling.
> > >>>>>
> > >>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> > >>>>>
> > >>>>> Or, does the patch below avoid the problem, at least?
> > >>>>>
> > >>>>>
> > >>>>> thanks,
> > >>>>>
> > >>>>> Takashi
> > >>>>>
> > >>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > >>>>> index 26a6cd3..5ceb228 100644
> > >>>>> --- a/sound/pci/sbxfi/sbxfi.c
> > >>>>> +++ b/sound/pci/sbxfi/sbxfi.c
> > >>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> > >>>>>  #else
> > >>>>>  
> > >>>>>  #define MAX_TICKS	((1 << 13) - 1)
> > >>>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
> > >>>>>  
> > >>>>>  static void sbxfi_init_timer(struct sbxfi *chip)
> > >>>>>  {
> > >>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> > >>>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> > >>>>>  	if (ticks > MAX_TICKS)
> > >>>>>  		ticks = MAX_TICKS;
> > >>>>> +	else if (ticks < MIN_TICKS)
> > >>>>> +		ticks = MIN_TICKS;
> > >>>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> > >>>>>  }
> > >>>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
> > >>>>>
> > >>>>>   
> > >>>>>       
> > >>>>>           
> > >>>> After patch:
> > >>>>
> > >>>> Without system timer:
> > >>>>
> > >>>> aplay --period-size=1024 96000_16_Stereo.wav
> > >>>> Plays fine
> > >>>>
> > >>>> aplay --period-size=1024 22050_16_Mono.wav
> > >>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> > >>>> Hang
> > >>>>
> > >>>> With system timer:
> > >>>>
> > >>>> aplay --period-size=1024 96000_16_Stereo.wav
> > >>>> Superglitch. Each sample is played many times before advancing to next one.
> > >>>>
> > >>>> aplay --period-size=1024 22050_16_Mono.wav
> > >>>> Instant reboot.
> > >>>>     
> > >>>>         
> > >>> Just to be sure: you don't enable XXX_CONT_RATE, right?
> > >>> It's known to be buggy, so disabled as default now.
> > >>>
> > >>>
> > >>> Takashi
> > >>>
> > >>>   
> > >>>       
> > >> It is disabled for me too.
> > >>     
> > >
> > > And the patch didn't help?
> > >
> > >
> > > Takashi
> > >
> > >   
> > Only 96000Hz Stereo without system timer plays fine after patch.
> 
> Please elaborate?  You mean 22.5k still doesn't work with the patch?
> Does 22.5kHz ever work with other parameters?  It'd be really helpful
> if you get the full Oops log...
> 
> The patch affects only the emu20k1 timer.  The system timer stuff
> isn't touched by it.
> 
> The reboot implies that it's unlikely the timer but the driver wrote
> something wrong (unless you have the set up that the kernel traps and
> automatically reboot).  But, it's nothing but a wild guess at this
> point.
> 
> Anyway, I updated the driver code a bit again.  Please check the
> latest one.

Only 96000Hz stereo works here as of 15 minutes ago. Following .asoundrc
stanzas result in a hardware fault and return to BIOS:

pcm.xfi-dmix {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:2,0"
        rate 96000
    }
}

pcm.xfi0 {
    type plug
    slave.pcm "xfi-dmix"
}

pcm.default pcm.xfi0

Unfortunately, nothing was left in /var/log/kern.log.

William

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Xarteras]

Takashi Iwai wrote:
> At Fri, 17 Oct 2008 14:16:38 +0400,
> The Source wrote:
>> Takashi Iwai пишет:
>>> At Fri, 17 Oct 2008 14:01:55 +0400,
>>> The Source wrote:
>>>   
>>>> Takashi Iwai пишет:
>>>>     
>>>>> At Fri, 17 Oct 2008 13:58:20 +0400,
>>>>> The Source wrote:
>>>>>   
>>>>>       
>>>>>> Takashi Iwai пишет:
>>>>>>     
>>>>>>         
>>>>>>> At Fri, 17 Oct 2008 11:57:08 +0400,
>>>>>>> The Source wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>> Takashi Iwai пишет:
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
>>>>>>>>> The Source wrote:
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
>>>>>>>>>>>>     
>>>>>>>>>>>>         
>>>>>>>>>>>>             
>>>>>>>>>>>>                 
>>>>>>>>>>>>                     
>>>>>>>>>>> In both cases, check the period_size and buffer_size values (shown in
>>>>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
>>>>>>>>>>> And, try to aplay with these parameters, whether you get the similar
>>>>>>>>>>> problem.
>>>>>>>>>>>
>>>>>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Takashi
>>>>>>>>>>>
>>>>>>>>>>>   
>>>>>>>>>>>       
>>>>>>>>>>>           
>>>>>>>>>>>               
>>>>>>>>>>>                   
>>>>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
>>>>>>>>>> system hang with error:
>>>>>>>>>> unable to handle NULL ponter dereference at address 
>>>>>>>>>> 0000000000000008.....(hang, no more output).
>>>>>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
>>>>>>>>>> sizes, sorry.
>>>>>>>>>>     
>>>>>>>>>>         
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
>>>>>>>>>
>>>>>>>>> I'm wondering whether this has anything to do with the capture.
>>>>>>>>> Can you record the sound, and change the capture mixer element properly?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> Takashi
>>>>>>>>>
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
>>>>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
>>>>>>>> when rate is lower).
>>>>>>>> However an attempt to play the same file with the same period and buffer 
>>>>>>>> sizes with aplay results in complete system hang.
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>> OK, that looks like a problem.  Looks like the timer resolution can be
>>>>>>> short like that, or something racy in the timer handling.
>>>>>>>
>>>>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
>>>>>>>
>>>>>>> Or, does the patch below avoid the problem, at least?
>>>>>>>
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Takashi
>>>>>>>
>>>>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
>>>>>>> index 26a6cd3..5ceb228 100644
>>>>>>> --- a/sound/pci/sbxfi/sbxfi.c
>>>>>>> +++ b/sound/pci/sbxfi/sbxfi.c
>>>>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
>>>>>>>  #else
>>>>>>>  
>>>>>>>  #define MAX_TICKS	((1 << 13) - 1)
>>>>>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
>>>>>>>  
>>>>>>>  static void sbxfi_init_timer(struct sbxfi *chip)
>>>>>>>  {
>>>>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
>>>>>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
>>>>>>>  	if (ticks > MAX_TICKS)
>>>>>>>  		ticks = MAX_TICKS;
>>>>>>> +	else if (ticks < MIN_TICKS)
>>>>>>> +		ticks = MIN_TICKS;
>>>>>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
>>>>>>>  }
>>>>>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>> After patch:
>>>>>>
>>>>>> Without system timer:
>>>>>>
>>>>>> aplay --period-size=1024 96000_16_Stereo.wav
>>>>>> Plays fine
>>>>>>
>>>>>> aplay --period-size=1024 22050_16_Mono.wav
>>>>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
>>>>>> Hang
>>>>>>
>>>>>> With system timer:
>>>>>>
>>>>>> aplay --period-size=1024 96000_16_Stereo.wav
>>>>>> Superglitch. Each sample is played many times before advancing to next one.
>>>>>>
>>>>>> aplay --period-size=1024 22050_16_Mono.wav
>>>>>> Instant reboot.
>>>>>>     
>>>>>>         
>>>>> Just to be sure: you don't enable XXX_CONT_RATE, right?
>>>>> It's known to be buggy, so disabled as default now.
>>>>>
>>>>>
>>>>> Takashi
>>>>>
>>>>>   
>>>>>       
>>>> It is disabled for me too.
>>>>     
>>> And the patch didn't help?
>>>
>>>
>>> Takashi
>>>
>>>   
>> Only 96000Hz Stereo without system timer plays fine after patch.
> 
> Please elaborate?  You mean 22.5k still doesn't work with the patch?
> Does 22.5kHz ever work with other parameters?  It'd be really helpful
> if you get the full Oops log...
> 
> The patch affects only the emu20k1 timer.  The system timer stuff
> isn't touched by it.
> 
> The reboot implies that it's unlikely the timer but the driver wrote
> something wrong (unless you have the set up that the kernel traps and
> automatically reboot).  But, it's nothing but a wild guess at this
> point.
> 
> Anyway, I updated the driver code a bit again.  Please check the
> latest one.

The latest change in the timer code really broke playback for me.
Sound now stutters every 2 seconds.
It seems to go back to normal when I put back the TIMR_IP flag that was 
commented out in that patch.

Jan Wolf
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Sat, 18 Oct 2008 10:06:20 +0000,
Xarteras wrote:
> 
> Takashi Iwai wrote:
> > At Fri, 17 Oct 2008 14:16:38 +0400,
> > The Source wrote:
> >> Takashi Iwai пишет:
> >>> At Fri, 17 Oct 2008 14:01:55 +0400,
> >>> The Source wrote:
> >>>   
> >>>> Takashi Iwai пишет:
> >>>>     
> >>>>> At Fri, 17 Oct 2008 13:58:20 +0400,
> >>>>> The Source wrote:
> >>>>>   
> >>>>>       
> >>>>>> Takashi Iwai пишет:
> >>>>>>     
> >>>>>>         
> >>>>>>> At Fri, 17 Oct 2008 11:57:08 +0400,
> >>>>>>> The Source wrote:
> >>>>>>>   
> >>>>>>>       
> >>>>>>>           
> >>>>>>>> Takashi Iwai пишет:
> >>>>>>>>     
> >>>>>>>>         
> >>>>>>>>             
> >>>>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> >>>>>>>>> The Source wrote:
> >>>>>>>>>   
> >>>>>>>>>       
> >>>>>>>>>           
> >>>>>>>>>               
> >>>>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> >>>>>>>>>>>>     
> >>>>>>>>>>>>         
> >>>>>>>>>>>>             
> >>>>>>>>>>>>                 
> >>>>>>>>>>>>                     
> >>>>>>>>>>> In both cases, check the period_size and buffer_size values (shown in
> >>>>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> >>>>>>>>>>> And, try to aplay with these parameters, whether you get the similar
> >>>>>>>>>>> problem.
> >>>>>>>>>>>
> >>>>>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Takashi
> >>>>>>>>>>>
> >>>>>>>>>>>   
> >>>>>>>>>>>       
> >>>>>>>>>>>           
> >>>>>>>>>>>               
> >>>>>>>>>>>                   
> >>>>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> >>>>>>>>>> system hang with error:
> >>>>>>>>>> unable to handle NULL ponter dereference at address 
> >>>>>>>>>> 0000000000000008.....(hang, no more output).
> >>>>>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
> >>>>>>>>>> sizes, sorry.
> >>>>>>>>>>     
> >>>>>>>>>>         
> >>>>>>>>>>             
> >>>>>>>>>>                 
> >>>>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> >>>>>>>>>
> >>>>>>>>> I'm wondering whether this has anything to do with the capture.
> >>>>>>>>> Can you record the sound, and change the capture mixer element properly?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> thanks,
> >>>>>>>>>
> >>>>>>>>> Takashi
> >>>>>>>>>
> >>>>>>>>>   
> >>>>>>>>>       
> >>>>>>>>>           
> >>>>>>>>>               
> >>>>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> >>>>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
> >>>>>>>> when rate is lower).
> >>>>>>>> However an attempt to play the same file with the same period and buffer 
> >>>>>>>> sizes with aplay results in complete system hang.
> >>>>>>>>     
> >>>>>>>>         
> >>>>>>>>             
> >>>>>>> OK, that looks like a problem.  Looks like the timer resolution can be
> >>>>>>> short like that, or something racy in the timer handling.
> >>>>>>>
> >>>>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> >>>>>>>
> >>>>>>> Or, does the patch below avoid the problem, at least?
> >>>>>>>
> >>>>>>>
> >>>>>>> thanks,
> >>>>>>>
> >>>>>>> Takashi
> >>>>>>>
> >>>>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> >>>>>>> index 26a6cd3..5ceb228 100644
> >>>>>>> --- a/sound/pci/sbxfi/sbxfi.c
> >>>>>>> +++ b/sound/pci/sbxfi/sbxfi.c
> >>>>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> >>>>>>>  #else
> >>>>>>>  
> >>>>>>>  #define MAX_TICKS	((1 << 13) - 1)
> >>>>>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
> >>>>>>>  
> >>>>>>>  static void sbxfi_init_timer(struct sbxfi *chip)
> >>>>>>>  {
> >>>>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> >>>>>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> >>>>>>>  	if (ticks > MAX_TICKS)
> >>>>>>>  		ticks = MAX_TICKS;
> >>>>>>> +	else if (ticks < MIN_TICKS)
> >>>>>>> +		ticks = MIN_TICKS;
> >>>>>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> >>>>>>>  }
> >>>>>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
> >>>>>>>
> >>>>>>>   
> >>>>>>>       
> >>>>>>>           
> >>>>>> After patch:
> >>>>>>
> >>>>>> Without system timer:
> >>>>>>
> >>>>>> aplay --period-size=1024 96000_16_Stereo.wav
> >>>>>> Plays fine
> >>>>>>
> >>>>>> aplay --period-size=1024 22050_16_Mono.wav
> >>>>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> >>>>>> Hang
> >>>>>>
> >>>>>> With system timer:
> >>>>>>
> >>>>>> aplay --period-size=1024 96000_16_Stereo.wav
> >>>>>> Superglitch. Each sample is played many times before advancing to next one.
> >>>>>>
> >>>>>> aplay --period-size=1024 22050_16_Mono.wav
> >>>>>> Instant reboot.
> >>>>>>     
> >>>>>>         
> >>>>> Just to be sure: you don't enable XXX_CONT_RATE, right?
> >>>>> It's known to be buggy, so disabled as default now.
> >>>>>
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>>   
> >>>>>       
> >>>> It is disabled for me too.
> >>>>     
> >>> And the patch didn't help?
> >>>
> >>>
> >>> Takashi
> >>>
> >>>   
> >> Only 96000Hz Stereo without system timer plays fine after patch.
> > 
> > Please elaborate?  You mean 22.5k still doesn't work with the patch?
> > Does 22.5kHz ever work with other parameters?  It'd be really helpful
> > if you get the full Oops log...
> > 
> > The patch affects only the emu20k1 timer.  The system timer stuff
> > isn't touched by it.
> > 
> > The reboot implies that it's unlikely the timer but the driver wrote
> > something wrong (unless you have the set up that the kernel traps and
> > automatically reboot).  But, it's nothing but a wild guess at this
> > point.
> > 
> > Anyway, I updated the driver code a bit again.  Please check the
> > latest one.
> 
> The latest change in the timer code really broke playback for me.
> Sound now stutters every 2 seconds.
> It seems to go back to normal when I put back the TIMR_IP flag that was 
> commented out in that patch.

Oh, thanks for noticing it.  I took the bit back now.
Looks like the bit is different from what I expected...


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 6962 bytes --]

On Sat, 2008-10-18 at 17:06 +0200, Takashi Iwai wrote:
> At Sat, 18 Oct 2008 10:06:20 +0000,
> Xarteras wrote:
> > 
> > Takashi Iwai wrote:
> > > At Fri, 17 Oct 2008 14:16:38 +0400,
> > > The Source wrote:
> > >> Takashi Iwai пишет:
> > >>> At Fri, 17 Oct 2008 14:01:55 +0400,
> > >>> The Source wrote:
> > >>>   
> > >>>> Takashi Iwai пишет:
> > >>>>     
> > >>>>> At Fri, 17 Oct 2008 13:58:20 +0400,
> > >>>>> The Source wrote:
> > >>>>>   
> > >>>>>       
> > >>>>>> Takashi Iwai пишет:
> > >>>>>>     
> > >>>>>>         
> > >>>>>>> At Fri, 17 Oct 2008 11:57:08 +0400,
> > >>>>>>> The Source wrote:
> > >>>>>>>   
> > >>>>>>>       
> > >>>>>>>           
> > >>>>>>>> Takashi Iwai пишет:
> > >>>>>>>>     
> > >>>>>>>>         
> > >>>>>>>>             
> > >>>>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> > >>>>>>>>> The Source wrote:
> > >>>>>>>>>   
> > >>>>>>>>>       
> > >>>>>>>>>           
> > >>>>>>>>>               
> > >>>>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> > >>>>>>>>>>>>     
> > >>>>>>>>>>>>         
> > >>>>>>>>>>>>             
> > >>>>>>>>>>>>                 
> > >>>>>>>>>>>>                     
> > >>>>>>>>>>> In both cases, check the period_size and buffer_size values (shown in
> > >>>>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> > >>>>>>>>>>> And, try to aplay with these parameters, whether you get the similar
> > >>>>>>>>>>> problem.
> > >>>>>>>>>>>
> > >>>>>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Takashi
> > >>>>>>>>>>>
> > >>>>>>>>>>>   
> > >>>>>>>>>>>       
> > >>>>>>>>>>>           
> > >>>>>>>>>>>               
> > >>>>>>>>>>>                   
> > >>>>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> > >>>>>>>>>> system hang with error:
> > >>>>>>>>>> unable to handle NULL ponter dereference at address 
> > >>>>>>>>>> 0000000000000008.....(hang, no more output).
> > >>>>>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
> > >>>>>>>>>> sizes, sorry.
> > >>>>>>>>>>     
> > >>>>>>>>>>         
> > >>>>>>>>>>             
> > >>>>>>>>>>                 
> > >>>>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> > >>>>>>>>>
> > >>>>>>>>> I'm wondering whether this has anything to do with the capture.
> > >>>>>>>>> Can you record the sound, and change the capture mixer element properly?
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> thanks,
> > >>>>>>>>>
> > >>>>>>>>> Takashi
> > >>>>>>>>>
> > >>>>>>>>>   
> > >>>>>>>>>       
> > >>>>>>>>>           
> > >>>>>>>>>               
> > >>>>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> > >>>>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
> > >>>>>>>> when rate is lower).
> > >>>>>>>> However an attempt to play the same file with the same period and buffer 
> > >>>>>>>> sizes with aplay results in complete system hang.
> > >>>>>>>>     
> > >>>>>>>>         
> > >>>>>>>>             
> > >>>>>>> OK, that looks like a problem.  Looks like the timer resolution can be
> > >>>>>>> short like that, or something racy in the timer handling.
> > >>>>>>>
> > >>>>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> > >>>>>>>
> > >>>>>>> Or, does the patch below avoid the problem, at least?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> thanks,
> > >>>>>>>
> > >>>>>>> Takashi
> > >>>>>>>
> > >>>>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > >>>>>>> index 26a6cd3..5ceb228 100644
> > >>>>>>> --- a/sound/pci/sbxfi/sbxfi.c
> > >>>>>>> +++ b/sound/pci/sbxfi/sbxfi.c
> > >>>>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> > >>>>>>>  #else
> > >>>>>>>  
> > >>>>>>>  #define MAX_TICKS	((1 << 13) - 1)
> > >>>>>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
> > >>>>>>>  
> > >>>>>>>  static void sbxfi_init_timer(struct sbxfi *chip)
> > >>>>>>>  {
> > >>>>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> > >>>>>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> > >>>>>>>  	if (ticks > MAX_TICKS)
> > >>>>>>>  		ticks = MAX_TICKS;
> > >>>>>>> +	else if (ticks < MIN_TICKS)
> > >>>>>>> +		ticks = MIN_TICKS;
> > >>>>>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> > >>>>>>>  }
> > >>>>>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
> > >>>>>>>
> > >>>>>>>   
> > >>>>>>>       
> > >>>>>>>           
> > >>>>>> After patch:
> > >>>>>>
> > >>>>>> Without system timer:
> > >>>>>>
> > >>>>>> aplay --period-size=1024 96000_16_Stereo.wav
> > >>>>>> Plays fine
> > >>>>>>
> > >>>>>> aplay --period-size=1024 22050_16_Mono.wav
> > >>>>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> > >>>>>> Hang
> > >>>>>>
> > >>>>>> With system timer:
> > >>>>>>
> > >>>>>> aplay --period-size=1024 96000_16_Stereo.wav
> > >>>>>> Superglitch. Each sample is played many times before advancing to next one.
> > >>>>>>
> > >>>>>> aplay --period-size=1024 22050_16_Mono.wav
> > >>>>>> Instant reboot.
> > >>>>>>     
> > >>>>>>         
> > >>>>> Just to be sure: you don't enable XXX_CONT_RATE, right?
> > >>>>> It's known to be buggy, so disabled as default now.
> > >>>>>
> > >>>>>
> > >>>>> Takashi
> > >>>>>
> > >>>>>   
> > >>>>>       
> > >>>> It is disabled for me too.
> > >>>>     
> > >>> And the patch didn't help?
> > >>>
> > >>>
> > >>> Takashi
> > >>>
> > >>>   
> > >> Only 96000Hz Stereo without system timer plays fine after patch.
> > > 
> > > Please elaborate?  You mean 22.5k still doesn't work with the patch?
> > > Does 22.5kHz ever work with other parameters?  It'd be really helpful
> > > if you get the full Oops log...
> > > 
> > > The patch affects only the emu20k1 timer.  The system timer stuff
> > > isn't touched by it.
> > > 
> > > The reboot implies that it's unlikely the timer but the driver wrote
> > > something wrong (unless you have the set up that the kernel traps and
> > > automatically reboot).  But, it's nothing but a wild guess at this
> > > point.
> > > 
> > > Anyway, I updated the driver code a bit again.  Please check the
> > > latest one.
> > 
> > The latest change in the timer code really broke playback for me.
> > Sound now stutters every 2 seconds.
> > It seems to go back to normal when I put back the TIMR_IP flag that was 
> > commented out in that patch.
> 
> Oh, thanks for noticing it.  I took the bit back now.
> Looks like the bit is different from what I expected...

Works in mpg123 (use -r 96000) again, breaks in Audacious and mplayer...
likely due to their non-blocking tickless model. Trying with various
period_time and buffer_size settings does not help.

William

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 7525 bytes --]

On Sat, 2008-10-18 at 12:10 -0500, William Pitcock wrote:
> On Sat, 2008-10-18 at 17:06 +0200, Takashi Iwai wrote:
> > At Sat, 18 Oct 2008 10:06:20 +0000,
> > Xarteras wrote:
> > > 
> > > Takashi Iwai wrote:
> > > > At Fri, 17 Oct 2008 14:16:38 +0400,
> > > > The Source wrote:
> > > >> Takashi Iwai пишет:
> > > >>> At Fri, 17 Oct 2008 14:01:55 +0400,
> > > >>> The Source wrote:
> > > >>>   
> > > >>>> Takashi Iwai пишет:
> > > >>>>     
> > > >>>>> At Fri, 17 Oct 2008 13:58:20 +0400,
> > > >>>>> The Source wrote:
> > > >>>>>   
> > > >>>>>       
> > > >>>>>> Takashi Iwai пишет:
> > > >>>>>>     
> > > >>>>>>         
> > > >>>>>>> At Fri, 17 Oct 2008 11:57:08 +0400,
> > > >>>>>>> The Source wrote:
> > > >>>>>>>   
> > > >>>>>>>       
> > > >>>>>>>           
> > > >>>>>>>> Takashi Iwai пишет:
> > > >>>>>>>>     
> > > >>>>>>>>         
> > > >>>>>>>>             
> > > >>>>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> > > >>>>>>>>> The Source wrote:
> > > >>>>>>>>>   
> > > >>>>>>>>>       
> > > >>>>>>>>>           
> > > >>>>>>>>>               
> > > >>>>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> > > >>>>>>>>>>>>     
> > > >>>>>>>>>>>>         
> > > >>>>>>>>>>>>             
> > > >>>>>>>>>>>>                 
> > > >>>>>>>>>>>>                     
> > > >>>>>>>>>>> In both cases, check the period_size and buffer_size values (shown in
> > > >>>>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> > > >>>>>>>>>>> And, try to aplay with these parameters, whether you get the similar
> > > >>>>>>>>>>> problem.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Takashi
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>   
> > > >>>>>>>>>>>       
> > > >>>>>>>>>>>           
> > > >>>>>>>>>>>               
> > > >>>>>>>>>>>                   
> > > >>>>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> > > >>>>>>>>>> system hang with error:
> > > >>>>>>>>>> unable to handle NULL ponter dereference at address 
> > > >>>>>>>>>> 0000000000000008.....(hang, no more output).
> > > >>>>>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
> > > >>>>>>>>>> sizes, sorry.
> > > >>>>>>>>>>     
> > > >>>>>>>>>>         
> > > >>>>>>>>>>             
> > > >>>>>>>>>>                 
> > > >>>>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> > > >>>>>>>>>
> > > >>>>>>>>> I'm wondering whether this has anything to do with the capture.
> > > >>>>>>>>> Can you record the sound, and change the capture mixer element properly?
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> thanks,
> > > >>>>>>>>>
> > > >>>>>>>>> Takashi
> > > >>>>>>>>>
> > > >>>>>>>>>   
> > > >>>>>>>>>       
> > > >>>>>>>>>           
> > > >>>>>>>>>               
> > > >>>>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> > > >>>>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
> > > >>>>>>>> when rate is lower).
> > > >>>>>>>> However an attempt to play the same file with the same period and buffer 
> > > >>>>>>>> sizes with aplay results in complete system hang.
> > > >>>>>>>>     
> > > >>>>>>>>         
> > > >>>>>>>>             
> > > >>>>>>> OK, that looks like a problem.  Looks like the timer resolution can be
> > > >>>>>>> short like that, or something racy in the timer handling.
> > > >>>>>>>
> > > >>>>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> > > >>>>>>>
> > > >>>>>>> Or, does the patch below avoid the problem, at least?
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> thanks,
> > > >>>>>>>
> > > >>>>>>> Takashi
> > > >>>>>>>
> > > >>>>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > > >>>>>>> index 26a6cd3..5ceb228 100644
> > > >>>>>>> --- a/sound/pci/sbxfi/sbxfi.c
> > > >>>>>>> +++ b/sound/pci/sbxfi/sbxfi.c
> > > >>>>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> > > >>>>>>>  #else
> > > >>>>>>>  
> > > >>>>>>>  #define MAX_TICKS	((1 << 13) - 1)
> > > >>>>>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
> > > >>>>>>>  
> > > >>>>>>>  static void sbxfi_init_timer(struct sbxfi *chip)
> > > >>>>>>>  {
> > > >>>>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> > > >>>>>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> > > >>>>>>>  	if (ticks > MAX_TICKS)
> > > >>>>>>>  		ticks = MAX_TICKS;
> > > >>>>>>> +	else if (ticks < MIN_TICKS)
> > > >>>>>>> +		ticks = MIN_TICKS;
> > > >>>>>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> > > >>>>>>>  }
> > > >>>>>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
> > > >>>>>>>
> > > >>>>>>>   
> > > >>>>>>>       
> > > >>>>>>>           
> > > >>>>>> After patch:
> > > >>>>>>
> > > >>>>>> Without system timer:
> > > >>>>>>
> > > >>>>>> aplay --period-size=1024 96000_16_Stereo.wav
> > > >>>>>> Plays fine
> > > >>>>>>
> > > >>>>>> aplay --period-size=1024 22050_16_Mono.wav
> > > >>>>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> > > >>>>>> Hang
> > > >>>>>>
> > > >>>>>> With system timer:
> > > >>>>>>
> > > >>>>>> aplay --period-size=1024 96000_16_Stereo.wav
> > > >>>>>> Superglitch. Each sample is played many times before advancing to next one.
> > > >>>>>>
> > > >>>>>> aplay --period-size=1024 22050_16_Mono.wav
> > > >>>>>> Instant reboot.
> > > >>>>>>     
> > > >>>>>>         
> > > >>>>> Just to be sure: you don't enable XXX_CONT_RATE, right?
> > > >>>>> It's known to be buggy, so disabled as default now.
> > > >>>>>
> > > >>>>>
> > > >>>>> Takashi
> > > >>>>>
> > > >>>>>   
> > > >>>>>       
> > > >>>> It is disabled for me too.
> > > >>>>     
> > > >>> And the patch didn't help?
> > > >>>
> > > >>>
> > > >>> Takashi
> > > >>>
> > > >>>   
> > > >> Only 96000Hz Stereo without system timer plays fine after patch.
> > > > 
> > > > Please elaborate?  You mean 22.5k still doesn't work with the patch?
> > > > Does 22.5kHz ever work with other parameters?  It'd be really helpful
> > > > if you get the full Oops log...
> > > > 
> > > > The patch affects only the emu20k1 timer.  The system timer stuff
> > > > isn't touched by it.
> > > > 
> > > > The reboot implies that it's unlikely the timer but the driver wrote
> > > > something wrong (unless you have the set up that the kernel traps and
> > > > automatically reboot).  But, it's nothing but a wild guess at this
> > > > point.
> > > > 
> > > > Anyway, I updated the driver code a bit again.  Please check the
> > > > latest one.
> > > 
> > > The latest change in the timer code really broke playback for me.
> > > Sound now stutters every 2 seconds.
> > > It seems to go back to normal when I put back the TIMR_IP flag that was 
> > > commented out in that patch.
> > 
> > Oh, thanks for noticing it.  I took the bit back now.
> > Looks like the bit is different from what I expected...
> 
> Works in mpg123 (use -r 96000) again, breaks in Audacious and mplayer...
> likely due to their non-blocking tickless model. Trying with various
> period_time and buffer_size settings does not help.

Figured it out. The hardware does not like period sizes larger than
4096. So we should manage a ringbuffer in the driver.

William

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Sat, 18 Oct 2008 12:17:04 -0500,
William Pitcock wrote:
> 
> On Sat, 2008-10-18 at 12:10 -0500, William Pitcock wrote:
> > On Sat, 2008-10-18 at 17:06 +0200, Takashi Iwai wrote:
> > > At Sat, 18 Oct 2008 10:06:20 +0000,
> > > Xarteras wrote:
> > > > 
> > > > Takashi Iwai wrote:
> > > > > At Fri, 17 Oct 2008 14:16:38 +0400,
> > > > > The Source wrote:
> > > > >> Takashi Iwai пишет:
> > > > >>> At Fri, 17 Oct 2008 14:01:55 +0400,
> > > > >>> The Source wrote:
> > > > >>>   
> > > > >>>> Takashi Iwai пишет:
> > > > >>>>     
> > > > >>>>> At Fri, 17 Oct 2008 13:58:20 +0400,
> > > > >>>>> The Source wrote:
> > > > >>>>>   
> > > > >>>>>       
> > > > >>>>>> Takashi Iwai пишет:
> > > > >>>>>>     
> > > > >>>>>>         
> > > > >>>>>>> At Fri, 17 Oct 2008 11:57:08 +0400,
> > > > >>>>>>> The Source wrote:
> > > > >>>>>>>   
> > > > >>>>>>>       
> > > > >>>>>>>           
> > > > >>>>>>>> Takashi Iwai пишет:
> > > > >>>>>>>>     
> > > > >>>>>>>>         
> > > > >>>>>>>>             
> > > > >>>>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> > > > >>>>>>>>> The Source wrote:
> > > > >>>>>>>>>   
> > > > >>>>>>>>>       
> > > > >>>>>>>>>           
> > > > >>>>>>>>>               
> > > > >>>>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> > > > >>>>>>>>>>>>     
> > > > >>>>>>>>>>>>         
> > > > >>>>>>>>>>>>             
> > > > >>>>>>>>>>>>                 
> > > > >>>>>>>>>>>>                     
> > > > >>>>>>>>>>> In both cases, check the period_size and buffer_size values (shown in
> > > > >>>>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> > > > >>>>>>>>>>> And, try to aplay with these parameters, whether you get the similar
> > > > >>>>>>>>>>> problem.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Takashi
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>   
> > > > >>>>>>>>>>>       
> > > > >>>>>>>>>>>           
> > > > >>>>>>>>>>>               
> > > > >>>>>>>>>>>                   
> > > > >>>>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> > > > >>>>>>>>>> system hang with error:
> > > > >>>>>>>>>> unable to handle NULL ponter dereference at address 
> > > > >>>>>>>>>> 0000000000000008.....(hang, no more output).
> > > > >>>>>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
> > > > >>>>>>>>>> sizes, sorry.
> > > > >>>>>>>>>>     
> > > > >>>>>>>>>>         
> > > > >>>>>>>>>>             
> > > > >>>>>>>>>>                 
> > > > >>>>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> > > > >>>>>>>>>
> > > > >>>>>>>>> I'm wondering whether this has anything to do with the capture.
> > > > >>>>>>>>> Can you record the sound, and change the capture mixer element properly?
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> thanks,
> > > > >>>>>>>>>
> > > > >>>>>>>>> Takashi
> > > > >>>>>>>>>
> > > > >>>>>>>>>   
> > > > >>>>>>>>>       
> > > > >>>>>>>>>           
> > > > >>>>>>>>>               
> > > > >>>>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> > > > >>>>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
> > > > >>>>>>>> when rate is lower).
> > > > >>>>>>>> However an attempt to play the same file with the same period and buffer 
> > > > >>>>>>>> sizes with aplay results in complete system hang.
> > > > >>>>>>>>     
> > > > >>>>>>>>         
> > > > >>>>>>>>             
> > > > >>>>>>> OK, that looks like a problem.  Looks like the timer resolution can be
> > > > >>>>>>> short like that, or something racy in the timer handling.
> > > > >>>>>>>
> > > > >>>>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> > > > >>>>>>>
> > > > >>>>>>> Or, does the patch below avoid the problem, at least?
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> thanks,
> > > > >>>>>>>
> > > > >>>>>>> Takashi
> > > > >>>>>>>
> > > > >>>>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > > > >>>>>>> index 26a6cd3..5ceb228 100644
> > > > >>>>>>> --- a/sound/pci/sbxfi/sbxfi.c
> > > > >>>>>>> +++ b/sound/pci/sbxfi/sbxfi.c
> > > > >>>>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> > > > >>>>>>>  #else
> > > > >>>>>>>  
> > > > >>>>>>>  #define MAX_TICKS	((1 << 13) - 1)
> > > > >>>>>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
> > > > >>>>>>>  
> > > > >>>>>>>  static void sbxfi_init_timer(struct sbxfi *chip)
> > > > >>>>>>>  {
> > > > >>>>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> > > > >>>>>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> > > > >>>>>>>  	if (ticks > MAX_TICKS)
> > > > >>>>>>>  		ticks = MAX_TICKS;
> > > > >>>>>>> +	else if (ticks < MIN_TICKS)
> > > > >>>>>>> +		ticks = MIN_TICKS;
> > > > >>>>>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> > > > >>>>>>>  }
> > > > >>>>>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
> > > > >>>>>>>
> > > > >>>>>>>   
> > > > >>>>>>>       
> > > > >>>>>>>           
> > > > >>>>>> After patch:
> > > > >>>>>>
> > > > >>>>>> Without system timer:
> > > > >>>>>>
> > > > >>>>>> aplay --period-size=1024 96000_16_Stereo.wav
> > > > >>>>>> Plays fine
> > > > >>>>>>
> > > > >>>>>> aplay --period-size=1024 22050_16_Mono.wav
> > > > >>>>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> > > > >>>>>> Hang
> > > > >>>>>>
> > > > >>>>>> With system timer:
> > > > >>>>>>
> > > > >>>>>> aplay --period-size=1024 96000_16_Stereo.wav
> > > > >>>>>> Superglitch. Each sample is played many times before advancing to next one.
> > > > >>>>>>
> > > > >>>>>> aplay --period-size=1024 22050_16_Mono.wav
> > > > >>>>>> Instant reboot.
> > > > >>>>>>     
> > > > >>>>>>         
> > > > >>>>> Just to be sure: you don't enable XXX_CONT_RATE, right?
> > > > >>>>> It's known to be buggy, so disabled as default now.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Takashi
> > > > >>>>>
> > > > >>>>>   
> > > > >>>>>       
> > > > >>>> It is disabled for me too.
> > > > >>>>     
> > > > >>> And the patch didn't help?
> > > > >>>
> > > > >>>
> > > > >>> Takashi
> > > > >>>
> > > > >>>   
> > > > >> Only 96000Hz Stereo without system timer plays fine after patch.
> > > > > 
> > > > > Please elaborate?  You mean 22.5k still doesn't work with the patch?
> > > > > Does 22.5kHz ever work with other parameters?  It'd be really helpful
> > > > > if you get the full Oops log...
> > > > > 
> > > > > The patch affects only the emu20k1 timer.  The system timer stuff
> > > > > isn't touched by it.
> > > > > 
> > > > > The reboot implies that it's unlikely the timer but the driver wrote
> > > > > something wrong (unless you have the set up that the kernel traps and
> > > > > automatically reboot).  But, it's nothing but a wild guess at this
> > > > > point.
> > > > > 
> > > > > Anyway, I updated the driver code a bit again.  Please check the
> > > > > latest one.
> > > > 
> > > > The latest change in the timer code really broke playback for me.
> > > > Sound now stutters every 2 seconds.
> > > > It seems to go back to normal when I put back the TIMR_IP flag that was 
> > > > commented out in that patch.
> > > 
> > > Oh, thanks for noticing it.  I took the bit back now.
> > > Looks like the bit is different from what I expected...
> > 
> > Works in mpg123 (use -r 96000) again, breaks in Audacious and mplayer...

"Break" means lock-up, or the sound quality?

> > likely due to their non-blocking tickless model. Trying with various
> > period_time and buffer_size settings does not help.
> 
> Figured it out. The hardware does not like period sizes larger than
> 4096. So we should manage a ringbuffer in the driver.

Interesting.  Is it a timer resolution issue, or loop size limitation?


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

By the way, the frontpannel headphone does not work.
Is it supposed to work?

http://us.creative.com/products/product.asp?category=209&subcategory=669&product=16559

(I Have this frontpannel but actually no X-RAM version of the X-Fi
series, or at least I can't remember that it has X-RAM)


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



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

Kind regards
Bjoern

Re: Backported sbxfi driver (UNTESTED!)

[William Pitcock]

[-- Attachment #1.1: Type: text/plain, Size: 2747 bytes --]

Nothing in the X-Fi drive works yet.

William

On Sun, 2008-10-19 at 20:07 +0200, Bjoern Olausson wrote:
> By the way, the frontpannel headphone does not work.
> Is it supposed to work?
> 
> http://us.creative.com/products/product.asp?category=209&subcategory=669&product=16559
> 
> (I Have this frontpannel but actually no X-RAM version of the X-Fi
> series, or at least I can't remember that it has X-RAM)
> 
> 
> 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
> 
> 
> 
> 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
> 
> Kind regards
> Bjoern
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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,

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

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,
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

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,
>>
>

Re: Backported sbxfi driver (UNTESTED!)

[The Source]

Hi, there's an entry in oss hg repo that they made some improvements to 
oss_sbxfi, you might want to take a look.

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Wed, 22 Oct 2008 23:25:11 +0400,
The Source wrote:
> 
> Hi, there's an entry in oss hg repo that they made some improvements to 
> oss_sbxfi, you might want to take a look.

Looks like no interesting changes.


Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

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]

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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
>   

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

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



[-- Attachment #2: sbxfi_oops_JH_23OCT08_1.txt --]
[-- Type: text/plain, Size: 2891 bytes --]

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


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

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

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Thu, 23 Oct 2008 13:46:35 +0200,
Bjoern Olausson wrote:
> 
> alsa-driver-unstable-snapshot.tar.bz2	2864 KB	10/22/2008 04:21:00 PM
> 
> Fails to compile

Fixed now.

thanks,

Takashi

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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
> 

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

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

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 10660 bytes --]

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


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

Re: Backported sbxfi driver (UNTESTED!)

[Bjoern Olausson]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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)

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

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

[-- Attachment #2: dmesg_after.txt --]
[-- Type: text/plain, Size: 8791 bytes --]

                                                              
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 ~]#


[-- Attachment #3: dmesg_modprobe.txt --]
[-- Type: text/plain, Size: 8721 bytes --]

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


[-- Attachment #4: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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);
 }

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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 ~]#

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

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


[-- Attachment #2: kernel.log.gz --]
[-- Type: application/x-gzip, Size: 19858 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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)

Re: Backported sbxfi driver (UNTESTED!)

[Jason Harvey]

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

Re: Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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

Backported sbxfi driver (UNTESTED!)

[Romain]

Hi,

I've tested the sbxfi driver and it works great on my setup.

Had little problems before getting it running :
i had to comment out the snd_printk stuff, otherwise the module wouldn't
load (snd_printk* symbols not found, in dmesg)
This was probably not the cleanest way to deal but  it's just debug messages
and i'm new wrt kernel driver hacking.
I also had to disable my onboard audio in BIOS, otherwise the X-Fi would not
get picked up.

i'm using Fedora 9 with Linux 2.6.26.6-79.fc9.i686 kernel (standard supply
from fedora repos),and pulseaudio
I'm using with standard 2.1 jack output, i do not yet own home cinema
speakers so i couldn't test all the cabling options.

Thanks for this great work,

Best Regards,
Romain.