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

Fwd: Backported sbxfi driver (UNTESTED!)

[The Source]

---------- Forwarded message ----------
From: The Source <thesourcehim@gmail.com>
Date: 2008/10/10
Subject: Re: [alsa-devel] Backported sbxfi driver (UNTESTED!)
To: Takashi Iwai <tiwai@suse.de>




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.

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

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

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

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

[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

Re: Backported sbxfi driver, possible fix

[Thomas Scheunemann]

I think I found a bug in the driver, which at least for me was
responsible for the crashes with pulseaudio.

A little backstory:

I have a Fedora 8 System with an SB X-Fi installed and of course
no sound. I didn't want to replace the entire ALSA driver, so I
just took the files sbxfi.c and emu20k1-regs.h from the unstable
sources, wrote a small spec-file and am now at a point where I
can just "rpm -i" the driver as a dkms package and just modprobe
the driver.

After that "speaker-test -D hw -c 2 -r 96000 -t sine" works just
fine, but as soon as pulseaudio is started my System froze.

The bug I think I found is in the get_xfi_order function. As long
as pages actually is a power of two it works correctly. But if
pages isn't a power of two it should round up, but it rounds down.
As a result I believe this screws up sbxfi_alloc_tlb_pages.

After a small modification to get_xfi_order:

--- /tmp/sbxfi.c	2008-10-25 14:51:55.000000000 +0200
+++ sbxfi.c	2008-10-25 14:03:48.000000000 +0200
@@ -851,11 +851,12 @@
 /* get the order of pages (power-of-two) */
 static int get_xfi_order(unsigned int pages)
 {
-	int order = -1;
-	do {
+	int order = 0;
+	pages--;
+	while(pages){
 		pages >>= 1;
 		order++;
-	} while (pages);
+	}
 	return order;
 }
 
the driver started working with pulseaudio, it doesn't crash, and I
even get sound though it still is a bit distorted.

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Sat, 25 Oct 2008 15:06:52 +0200,
Thomas Scheunemann wrote:
> 
> I think I found a bug in the driver, which at least for me was
> responsible for the crashes with pulseaudio.
> 
> A little backstory:
> 
> I have a Fedora 8 System with an SB X-Fi installed and of course
> no sound. I didn't want to replace the entire ALSA driver, so I
> just took the files sbxfi.c and emu20k1-regs.h from the unstable
> sources, wrote a small spec-file and am now at a point where I
> can just "rpm -i" the driver as a dkms package and just modprobe
> the driver.
> 
> After that "speaker-test -D hw -c 2 -r 96000 -t sine" works just
> fine, but as soon as pulseaudio is started my System froze.
> 
> The bug I think I found is in the get_xfi_order function. As long
> as pages actually is a power of two it works correctly. But if
> pages isn't a power of two it should round up, but it rounds down.
> As a result I believe this screws up sbxfi_alloc_tlb_pages.
> 
> After a small modification to get_xfi_order:

Thanks for the patch.
Yeah, I found the very same problem in this morning, but I couldn't
update the repo and snapshot until now due to the server crash.

My solution is to use roundup_pow_of_two() instead of the own
funciton.  This should work better in general.

Anyway, I updated the repo (and rebased, sorry), updated the snapshot,
too.

thanks,

Takashi


> --- /tmp/sbxfi.c	2008-10-25 14:51:55.000000000 +0200
> +++ sbxfi.c	2008-10-25 14:03:48.000000000 +0200
> @@ -851,11 +851,12 @@
>  /* get the order of pages (power-of-two) */
>  static int get_xfi_order(unsigned int pages)
>  {
> -	int order = -1;
> -	do {
> +	int order = 0;
> +	pages--;
> +	while(pages){
>  		pages >>= 1;
>  		order++;
> -	} while (pages);
> +	}
>  	return order;
>  }
>  
> the driver started working with pulseaudio, it doesn't crash, and I
> even get sound though it still is a bit distorted.
> 

Re: Backported sbxfi driver, possible fix

[Thomas Scheunemann]

> My solution is to use roundup_pow_of_two() instead of the own
> funciton.  This should work better in general.

I certainly agree that it is better to use an already defined function
instead of reinventing the wheel.

> Anyway, I updated the repo (and rebased, sorry), updated the snapshot,
> too.

But this new version causes an immediate reboot on my machine even with
the previously working speaker-test. If I interpret linux/log2.h correctly
the desired function should be order_base_2 instead of roundup_pow_of_two.
At least it works for me after that exchange.

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Sat, 25 Oct 2008 21:42:55 +0200,
Thomas Scheunemann wrote:
> 
> > My solution is to use roundup_pow_of_two() instead of the own
> > funciton.  This should work better in general.
> 
> I certainly agree that it is better to use an already defined function
> instead of reinventing the wheel.
> 
> > Anyway, I updated the repo (and rebased, sorry), updated the snapshot,
> > too.
> 
> But this new version causes an immediate reboot on my machine even with
> the previously working speaker-test. If I interpret linux/log2.h correctly
> the desired function should be order_base_2 instead of roundup_pow_of_two.
> At least it works for me after that exchange.

Oh my.  You're right, it must be order_base_2(), of course.
I was too hurry to fix a bug after the server crash :)

Now fixed and updated.  Thanks!

Takashi

Re: Backported sbxfi driver, possible fix

[Jason Harvey]

Takashi Iwai wrote:
> At Sat, 25 Oct 2008 21:42:55 +0200,
> Thomas Scheunemann wrote:
>   
>>> My solution is to use roundup_pow_of_two() instead of the own
>>> funciton.  This should work better in general.
>>>       
>> I certainly agree that it is better to use an already defined function
>> instead of reinventing the wheel.
>>
>>     
>>> Anyway, I updated the repo (and rebased, sorry), updated the snapshot,
>>> too.
>>>       
>> But this new version causes an immediate reboot on my machine even with
>> the previously working speaker-test. If I interpret linux/log2.h correctly
>> the desired function should be order_base_2 instead of roundup_pow_of_two.
>> At least it works for me after that exchange.
>>     
>
> Oh my.  You're right, it must be order_base_2(), of course.
> I was too hurry to fix a bug after the server crash :)
>
> Now fixed and updated.  Thanks!
>   
Latest unstable (25Oct 19:57) works from command line with mplayer, 
without the proc oss fix.
aplay still works but only with dmix.
Now also almost working in gnome with pulse, sound is recognisable but 
with lots of interference/corruption.
Machine did not crash at any point!

This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 
2.6.25 or earlier?

Jason

Re: Backported sbxfi driver, possible fix

[Bjoern Olausson]

> Latest unstable (25Oct 19:57) works from command line with mplayer,
> without the proc oss fix.
>
Confirmed.
The stuttering got better, but is still present.

Xine works flawless.

> aplay still works but only with dmix.
>
Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
bit scratchy..
All other common samplingrates work flawless. Could someone confirm that?
http://tmp.olausson.de/30days/0_16_s_8000.wav
http://tmp.olausson.de/30days/0_16_s_11025.wav
http://tmp.olausson.de/30days/0_16_s_96000.wav

Just using "aplay file.wav"

More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz
"mplayer file.wav"

mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.

> Now also almost working in gnome with pulse, sound is recognisable but
> with lots of interference/corruption.
>
No pulseaudio on my machine. Sry.

> Machine did not crash at any point!
>
Just observed a X crash when using smplayer to play a avi. When I
closed smplayer while the movie was playing X crashed. (But could be
unrelated to audio, I could not reproduce it)

But no crash or freez so far.

> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
> 2.6.25 or earlier?
>
I am using vanilla 2.6.27.3

Thanks for you awesome work!

By the way, what's next on your plan when stereo output and recording
is working flawless?


kind regards
Bjoern

Re: Backported sbxfi driver, possible fix

[The Source]

Bjoern Olausson пишет:
>> Latest unstable (25Oct 19:57) works from command line with mplayer,
>> without the proc oss fix.
>>
>>     
> Confirmed.
> The stuttering got better, but is still present.
>
> Xine works flawless.
>
>   
>> aplay still works but only with dmix.
>>
>>     
> Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
> bit scratchy..
> All other common samplingrates work flawless. Could someone confirm that?
> http://tmp.olausson.de/30days/0_16_s_8000.wav
> http://tmp.olausson.de/30days/0_16_s_11025.wav
> http://tmp.olausson.de/30days/0_16_s_96000.wav
>
> Just using "aplay file.wav"
>
> More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz
> "mplayer file.wav"
>
> mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
>
>   
>> Now also almost working in gnome with pulse, sound is recognisable but
>> with lots of interference/corruption.
>>
>>     
> No pulseaudio on my machine. Sry.
>
>   
>> Machine did not crash at any point!
>>
>>     
> Just observed a X crash when using smplayer to play a avi. When I
> closed smplayer while the movie was playing X crashed. (But could be
> unrelated to audio, I could not reproduce it)
>
> But no crash or freez so far.
>
>   
>> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
>> 2.6.25 or earlier?
>>
>>     
> I am using vanilla 2.6.27.3
>
> Thanks for you awesome work!
>
> By the way, what's next on your plan when stereo output and recording
> is working flawless?
>
>
> kind regards
> Bjoern
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>   
Tried the latest driver.
All is fine (haven't tested recording however) except pulseaudio 
(doesn't work) and wine (sound is mega-glitchy, possibly because of 
strange period and buffer sizes it uses: period=544, buffer=8704). 
System is stable. OSS works fine.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver, possible fix

[The Source]

Bjoern Olausson пишет:
>> Latest unstable (25Oct 19:57) works from command line with mplayer,
>> without the proc oss fix.
>>
>>     
> Confirmed.
> The stuttering got better, but is still present.
>
> Xine works flawless.
>
>   
>> aplay still works but only with dmix.
>>
>>     
> Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
> bit scratchy..
> All other common samplingrates work flawless. Could someone confirm that?
> http://tmp.olausson.de/30days/0_16_s_8000.wav
> http://tmp.olausson.de/30days/0_16_s_11025.wav
> http://tmp.olausson.de/30days/0_16_s_96000.wav
>
> Just using "aplay file.wav"
>
> More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz
> "mplayer file.wav"
>
> mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
>
>   
>> Now also almost working in gnome with pulse, sound is recognisable but
>> with lots of interference/corruption.
>>
>>     
> No pulseaudio on my machine. Sry.
>
>   
>> Machine did not crash at any point!
>>
>>     
> Just observed a X crash when using smplayer to play a avi. When I
> closed smplayer while the movie was playing X crashed. (But could be
> unrelated to audio, I could not reproduce it)
>
> But no crash or freez so far.
>
>   
>> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
>> 2.6.25 or earlier?
>>
>>     
> I am using vanilla 2.6.27.3
>
> Thanks for you awesome work!
>
> By the way, what's next on your plan when stereo output and recording
> is working flawless?
>
>
> kind regards
> Bjoern
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>   
--Tried the latest driver.
--All is fine (haven't tested recording however) except pulseaudio
--(doesn't work) and wine (sound is mega-glitchy, possibly because of
--strange period and buffer sizes it uses: period=544, buffer=8704).
--System is stable. OSS works fine.

Also dmix causes horrible glitches everywhere. Was anyone able to make 
good dmix config?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver, possible fix

[The Source]

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

Bjoern Olausson пишет:
>> Latest unstable (25Oct 19:57) works from command line with mplayer,
>> without the proc oss fix.
>>
>>     
> Confirmed.
> The stuttering got better, but is still present.
>
> Xine works flawless.
>
>   
>> aplay still works but only with dmix.
>>
>>     
> Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
> bit scratchy..
> All other common samplingrates work flawless. Could someone confirm that?
> http://tmp.olausson.de/30days/0_16_s_8000.wav
> http://tmp.olausson.de/30days/0_16_s_11025.wav
> http://tmp.olausson.de/30days/0_16_s_96000.wav
>
> Just using "aplay file.wav"
>
> More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz
> "mplayer file.wav"
>
> mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
>
>   
>> Now also almost working in gnome with pulse, sound is recognisable but
>> with lots of interference/corruption.
>>
>>     
> No pulseaudio on my machine. Sry.
>
>   
>> Machine did not crash at any point!
>>
>>     
> Just observed a X crash when using smplayer to play a avi. When I
> closed smplayer while the movie was playing X crashed. (But could be
> unrelated to audio, I could not reproduce it)
>
> But no crash or freez so far.
>
>   
>> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
>> 2.6.25 or earlier?
>>
>>     
> I am using vanilla 2.6.27.3
>
> Thanks for you awesome work!
>
> By the way, what's next on your plan when stereo output and recording
> is working flawless?
>
>
> kind regards
> Bjoern
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
>   
--Tried the latest driver.
--All is fine (haven't tested recording however) except pulseaudio
--(doesn't work) and wine (sound is mega-glitchy, possibly because of
--strange period and buffer sizes it uses: period=544, buffer=8704).
--System is stable. OSS works fine.

--Also dmix causes horrible glitches everywhere. Was anyone able to make
--good dmix config?

Hmmm.. Looks like it is not dmix fault. wine requested something of
driver that caused all sound to be glitchy until driver is reloaded.
dmesg output with debug=3 is attached.
Here's some wine output:
fixme:wave:ALSA_ComputeCaps Device has a minimum of 2 channels
fixme:wave:ALSA_ComputeCaps Device has a minimum of 2 channels
fixme:wtsapi:WTSRegisterSessionNotification Stub 0x1004e 0x00000000
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x1ac8c8,0x1ad118): stub
fixme:dsalsa:CheckXRUN Unhandled state: 0
mixer.c:305: DSOUND_BufPtrDiff: Assertion `ptr2 < buflen' failed.
wine: Assertion failed at address 0x60000812 (thread 001c), starting
debugger...
Unhandled exception: assertion failed in 32-bit code (0x60000812).
Register dump:
  CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
  EIP:60000812 ESP:7db9e740 EBP:7db9e74c EFLAGS:00200206(   - 00      -
-IP1)
  EAX:00000000 EBX:00001605 ECX:0000161a EDX:00000006
  ESI:602a607a EDI:602d2ff4
Stack dump:
0x7db9e740:  60198660 602d2ff4 7db9e86c 7db9e874
0x7db9e750:  6019a028 00000006 7db9e7ec 00000000
0x7db9e760:  602d2ff4 00000043 7d394298 00000068
0x7db9e770:  601db11f 7db9e7b0 7d3942a0 7d3942a0
0x7db9e780:  601ac78b 602d2ff4 00000043 7d3942a0
0x7db9e790:  7db9e85c 601d444b 7d3942a0 00000043
Backtrace:
=>1 0x60000812 (0x7db9e74c)
   2 0x6019a028 (0x7db9e874)
   3 0x6019157e (0x7db9e8b8)
   4 0x613afc86 DSOUND_timer+0x1336() in dsound (0x7db9e9a8)
   5 0x60a88bc8 in winmm (+0x28bc8) (0x7db9ea18)
   6 0x603471fe call_thread_entry_point+0xe() in ntdll (0x7db9ea28)
   7 0x60348832 in ntdll (+0x58832) (0x7db9eac8)
   8 0x60348a2d in ntdll (+0x58a2d) (0x7db9f3b8)
   9 0x6015b32f (0x7db9f4b8)
0x60000812: ret	
Modules:
Module	Address			Debug info	Name (124 modules)
ELF	  1dd000-  20c000	Deferred        libgssapi_krb5.so.2
ELF	  227000-  24e000	Deferred        libexpat.so.1
ELF	  250000-  27f000	Deferred        libfontconfig.so.1
ELF	  281000-  28a000	Deferred        libxrender.so.1
ELF	  28c000-  38d000	Deferred        libx11.so.6
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
PE	  400000-  723000	Deferred        qip
ELF	  ab5000-  abd000	Deferred        libsm.so.6
ELF	  abf000-  ac3000	Deferred        libuuid.so.1
ELF	  ae9000-  aec000	Deferred        libcom_err.so.2
ELF	  af5000-  afc000	Deferred        libxrandr.so.2
ELF	  b1d000-  b20000	Deferred        libxcomposite.so.1
ELF	  b22000-  b3c000	Deferred        libice.so.6
ELF	  bf4000-  bf7000	Deferred        libkeyutils.so.1
ELF	  bfa000-  c18000	Deferred        ld-linux.so.2
ELF	  c1a000-  d83000	Deferred        libc.so.6
ELF	  d85000-  d8a000	Deferred        libdl.so.2
ELF	  d8c000-  da5000	Deferred        libpthread.so.0
ELF	  da7000-  dd0000	Deferred        libm.so.6
ELF	  dd2000-  dee000	Deferred        libselinux.so.1
PE	  ff0000- 1465000	Deferred        flash10a
ELF	 5ca1000- 5cb6000	Deferred        libresolv.so.2
ELF	 5d41000- 5d66000	Deferred        libk5crypto.so.3
ELF	 5d99000- 5dcb000	Deferred        libcrypt.so.1
ELF	 5f01000- 5f0a000	Deferred        libkrb5support.so.0
PE	10000000-10010000	Deferred        docking
ELF	6001e000-60155000	Deferred        libwine.so.1
ELF	602dc000-6038b000	Export          ntdll<elf>
   \-PE	602f0000-6038b000	\               ntdll
ELF	603b4000-604ff000	Deferred        kernel32<elf>
   \-PE	603d0000-604ff000	\               kernel32
ELF	604ff000-60558000	Deferred        advapi32<elf>
   \-PE	60510000-60558000	\               advapi32
ELF	60558000-60679000	Deferred        ole32<elf>
   \-PE	60570000-60679000	\               ole32
ELF	60679000-606e4000	Deferred        rpcrt4<elf>
   \-PE	60680000-606e4000	\               rpcrt4
ELF	606e4000-60704000	Deferred        iphlpapi<elf>
   \-PE	606f0000-60704000	\               iphlpapi
ELF	60719000-60733000	Deferred        version<elf>
   \-PE	60720000-60733000	\               version
ELF	60733000-607ff000	Deferred        comctl32<elf>
   \-PE	60740000-607ff000	\               comctl32
ELF	607ff000-60820000	Deferred        imm32<elf>
   \-PE	60810000-60820000	\               imm32
ELF	60820000-60944000	Deferred        shell32<elf>
   \-PE	60830000-60944000	\               shell32
ELF	60944000-609a3000	Deferred        shlwapi<elf>
   \-PE	60950000-609a3000	\               shlwapi
ELF	609a3000-60a52000	Deferred        comdlg32<elf>
   \-PE	609b0000-60a52000	\               comdlg32
ELF	60a52000-60ae9000	Export          winmm<elf>
   \-PE	60a60000-60ae9000	\               winmm
ELF	60b9f000-60c3f000	Deferred        winex11<elf>
   \-PE	60bb0000-60c3f000	\               winex11
ELF	60d79000-60d7b000	Deferred        libxcb-xlib.so.0
ELF	60d7b000-60d97000	Deferred        libxcb.so.1
ELF	60da0000-60da5000	Deferred        libxxf86vm.so.1
ELF	60dc7000-60dfa000	Deferred        uxtheme<elf>
   \-PE	60dd0000-60dfa000	\               uxtheme
ELF	60dfa000-60e34000	Deferred        libcups.so.2
ELF	60f2b000-60fa9000	Deferred        libgnutls.so.13
ELF	60ffb000-6100c000	Deferred        libtasn1.so.3
ELF	6100c000-6107b000	Deferred        libgcrypt.so.11
ELF	6107b000-6107f000	Deferred        libgpg-error.so.0
ELF	6109b000-610d2000	Deferred        winealsa<elf>
   \-PE	610a0000-610d2000	\               winealsa
ELF	610d2000-611b4000	Deferred        libasound.so.2
ELF	611be000-611d6000	Deferred        msacm32<elf>
   \-PE	611c0000-611d6000	\               msacm32
ELF	611d6000-611ff000	Deferred        msacm32<elf>
   \-PE	611e0000-611ff000	\               msacm32
ELF	611ff000-61214000	Deferred        midimap<elf>
   \-PE	61200000-61214000	\               midimap
ELF	61214000-61227000	Deferred        olepro32<elf>
   \-PE	61220000-61227000	\               olepro32
ELF	61227000-61255000	Deferred        d3d8<elf>
   \-PE	61230000-61255000	\               d3d8
ELF	61255000-61383000	Deferred        wined3d<elf>
   \-PE	61270000-61383000	\               wined3d
ELF	61383000-613d1000	Export          dsound<elf>
   \-PE	61390000-613d1000	\               dsound
ELF	613d1000-613e4000	Deferred        security<elf>
   \-PE	613e0000-613e4000	\               security
ELF	613e4000-6140b000	Deferred        netapi32<elf>
   \-PE	613f0000-6140b000	\               netapi32
ELF	6140b000-61439000	Deferred        ws2_32<elf>
   \-PE	61410000-61439000	\               ws2_32
ELF	61439000-6148b000	Deferred        wininet<elf>
   \-PE	61440000-6148b000	\               wininet
ELF	6148b000-614ae000	Deferred        mpr<elf>
   \-PE	61490000-614ae000	\               mpr
ELF	614ae000-61524000	Deferred        crypt32<elf>
   \-PE	614c0000-61524000	\               crypt32
ELF	61524000-61567000	Deferred        urlmon<elf>
   \-PE	61530000-61567000	\               urlmon
ELF	61567000-61585000	Deferred        mscms<elf>
   \-PE	61570000-61585000	\               mscms
ELF	61585000-615bd000	Deferred        liblcms.so.1
ELF	615bd000-615ff000	Deferred        shdocvw<elf>
   \-PE	615c0000-615ff000	\               shdocvw
ELF	63ef9000-63f05000	Deferred        libnss_files.so.2
ELF	66685000-66699000	Deferred        lz32<elf>
   \-PE	66690000-66699000	\               lz32
ELF	6c32d000-6c3d5000	Deferred        gdi32<elf>
   \-PE	6c340000-6c3d5000	\               gdi32
ELF	6c3e1000-6c53d000	Deferred        user32<elf>
   \-PE	6c400000-6c53d000	\               user32
ELF	6fbfd000-6fc34000	Deferred        winspool<elf>
   \-PE	6fc00000-6fc34000	\               winspool
ELF	735b3000-736af000	Deferred        oleaut32<elf>
   \-PE	735d0000-736af000	\               oleaut32
ELF	73903000-7392c000	Deferred        secur32<elf>
   \-PE	73910000-7392c000	\               secur32
ELF	7bf00000-7bf03000	Deferred        <wine-loader>
Threads:
process  tid      prio (all id:s are in hex)
00000008 (D) C:\Program Files\QIP\qip.exe
	0000001c   15 <==
	0000001b    0
	0000001a    0
	00000019    0
	00000018    0
	00000009    0
0000000c
	00000014    0
	00000013    0
	00000012    0
	0000000e    0
	0000000d    0
0000000f
	00000015    0
	00000011    0
	00000010    0
00000016
	00000017    0
Backtrace:
=>1 0x60000812 (0x7db9e74c)
   2 0x6019a028 (0x7db9e874)
   3 0x6019157e (0x7db9e8b8)
   4 0x613afc86 DSOUND_timer+0x1336() in dsound (0x7db9e9a8)
   5 0x60a88bc8 in winmm (+0x28bc8) (0x7db9ea18)
   6 0x603471fe call_thread_entry_point+0xe() in ntdll (0x7db9ea28)
   7 0x60348832 in ntdll (+0x58832) (0x7db9eac8)
   8 0x60348a2d in ntdll (+0x58a2d) (0x7db9f3b8)
   9 0x6015b32f (0x7db9f4b8)


[-- Attachment #2: dmesg.out.bz2 --]
[-- Type: application/x-bzip, Size: 1790 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, possible fix

[The Source]

The Source пишет:
> Bjoern Olausson пишет:
>>> Latest unstable (25Oct 19:57) works from command line with mplayer,
>>> without the proc oss fix.
>>>
>>>     
>> Confirmed.
>> The stuttering got better, but is still present.
>>
>> Xine works flawless.
>>
>>  
>>> aplay still works but only with dmix.
>>>
>>>     
>> Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
>> bit scratchy..
>> All other common samplingrates work flawless. Could someone confirm 
>> that?
>> http://tmp.olausson.de/30days/0_16_s_8000.wav
>> http://tmp.olausson.de/30days/0_16_s_11025.wav
>> http://tmp.olausson.de/30days/0_16_s_96000.wav
>>
>> Just using "aplay file.wav"
>>
>> More noticable ist it when using mplayer. Crackles a lot with 8000Hz 
>> and 11025Hz
>> "mplayer file.wav"
>>
>> mmh, xine crackles too. Please someone confirm, otherwise the files 
>> may be bad.
>>
>>  
>>> Now also almost working in gnome with pulse, sound is recognisable but
>>> with lots of interference/corruption.
>>>
>>>     
>> No pulseaudio on my machine. Sry.
>>
>>  
>>> Machine did not crash at any point!
>>>
>>>     
>> Just observed a X crash when using smplayer to play a avi. When I
>> closed smplayer while the movie was playing X crashed. (But could be
>> unrelated to audio, I could not reproduce it)
>>
>> But no crash or freez so far.
>>
>>  
>>> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
>>> 2.6.25 or earlier?
>>>
>>>     
>> I am using vanilla 2.6.27.3
>>
>> Thanks for you awesome work!
>>
>> By the way, what's next on your plan when stereo output and recording
>> is working flawless?
>>
>>
>> kind regards
>> Bjoern
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
>>   
> --Tried the latest driver.
> --All is fine (haven't tested recording however) except pulseaudio
> --(doesn't work) and wine (sound is mega-glitchy, possibly because of
> --strange period and buffer sizes it uses: period=544, buffer=8704).
> --System is stable. OSS works fine.
>
> --Also dmix causes horrible glitches everywhere. Was anyone able to make
> --good dmix config?
>
> Hmmm.. Looks like it is not dmix fault. wine requested something of
> driver that caused all sound to be glitchy until driver is reloaded.
> dmesg output with debug=3 is attached.
> Here's some wine output:
> fixme:wave:ALSA_ComputeCaps Device has a minimum of 2 channels
> fixme:wave:ALSA_ComputeCaps Device has a minimum of 2 channels
> fixme:wtsapi:WTSRegisterSessionNotification Stub 0x1004e 0x00000000
> fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x1ac8c8,0x1ad118): stub
> fixme:dsalsa:CheckXRUN Unhandled state: 0
> mixer.c:305: DSOUND_BufPtrDiff: Assertion `ptr2 < buflen' failed.
> wine: Assertion failed at address 0x60000812 (thread 001c), starting
> debugger...
> Unhandled exception: assertion failed in 32-bit code (0x60000812).
> Register dump:
>  CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
>  EIP:60000812 ESP:7db9e740 EBP:7db9e74c EFLAGS:00200206(   - 00      -
> -IP1)
>  EAX:00000000 EBX:00001605 ECX:0000161a EDX:00000006
>  ESI:602a607a EDI:602d2ff4
> Stack dump:
> 0x7db9e740:  60198660 602d2ff4 7db9e86c 7db9e874
> 0x7db9e750:  6019a028 00000006 7db9e7ec 00000000
> 0x7db9e760:  602d2ff4 00000043 7d394298 00000068
> 0x7db9e770:  601db11f 7db9e7b0 7d3942a0 7d3942a0
> 0x7db9e780:  601ac78b 602d2ff4 00000043 7d3942a0
> 0x7db9e790:  7db9e85c 601d444b 7d3942a0 00000043
> Backtrace:
> =>1 0x60000812 (0x7db9e74c)
>   2 0x6019a028 (0x7db9e874)
>   3 0x6019157e (0x7db9e8b8)
>   4 0x613afc86 DSOUND_timer+0x1336() in dsound (0x7db9e9a8)
>   5 0x60a88bc8 in winmm (+0x28bc8) (0x7db9ea18)
>   6 0x603471fe call_thread_entry_point+0xe() in ntdll (0x7db9ea28)
>   7 0x60348832 in ntdll (+0x58832) (0x7db9eac8)
>   8 0x60348a2d in ntdll (+0x58a2d) (0x7db9f3b8)
>   9 0x6015b32f (0x7db9f4b8)
> 0x60000812: ret   
> Modules:
> Module    Address            Debug info    Name (124 modules)
> ELF      1dd000-  20c000    Deferred        libgssapi_krb5.so.2
> ELF      227000-  24e000    Deferred        libexpat.so.1
> ELF      250000-  27f000    Deferred        libfontconfig.so.1
> ELF      281000-  28a000    Deferred        libxrender.so.1
> ELF      28c000-  38d000    Deferred        libx11.so.6
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> PE      400000-  723000    Deferred        qip
> ELF      ab5000-  abd000    Deferred        libsm.so.6
> ELF      abf000-  ac3000    Deferred        libuuid.so.1
> ELF      ae9000-  aec000    Deferred        libcom_err.so.2
> ELF      af5000-  afc000    Deferred        libxrandr.so.2
> ELF      b1d000-  b20000    Deferred        libxcomposite.so.1
> ELF      b22000-  b3c000    Deferred        libice.so.6
> ELF      bf4000-  bf7000    Deferred        libkeyutils.so.1
> ELF      bfa000-  c18000    Deferred        ld-linux.so.2
> ELF      c1a000-  d83000    Deferred        libc.so.6
> ELF      d85000-  d8a000    Deferred        libdl.so.2
> ELF      d8c000-  da5000    Deferred        libpthread.so.0
> ELF      da7000-  dd0000    Deferred        libm.so.6
> ELF      dd2000-  dee000    Deferred        libselinux.so.1
> PE      ff0000- 1465000    Deferred        flash10a
> ELF     5ca1000- 5cb6000    Deferred        libresolv.so.2
> ELF     5d41000- 5d66000    Deferred        libk5crypto.so.3
> ELF     5d99000- 5dcb000    Deferred        libcrypt.so.1
> ELF     5f01000- 5f0a000    Deferred        libkrb5support.so.0
> PE    10000000-10010000    Deferred        docking
> ELF    6001e000-60155000    Deferred        libwine.so.1
> ELF    602dc000-6038b000    Export          ntdll<elf>
>   \-PE    602f0000-6038b000    \               ntdll
> ELF    603b4000-604ff000    Deferred        kernel32<elf>
>   \-PE    603d0000-604ff000    \               kernel32
> ELF    604ff000-60558000    Deferred        advapi32<elf>
>   \-PE    60510000-60558000    \               advapi32
> ELF    60558000-60679000    Deferred        ole32<elf>
>   \-PE    60570000-60679000    \               ole32
> ELF    60679000-606e4000    Deferred        rpcrt4<elf>
>   \-PE    60680000-606e4000    \               rpcrt4
> ELF    606e4000-60704000    Deferred        iphlpapi<elf>
>   \-PE    606f0000-60704000    \               iphlpapi
> ELF    60719000-60733000    Deferred        version<elf>
>   \-PE    60720000-60733000    \               version
> ELF    60733000-607ff000    Deferred        comctl32<elf>
>   \-PE    60740000-607ff000    \               comctl32
> ELF    607ff000-60820000    Deferred        imm32<elf>
>   \-PE    60810000-60820000    \               imm32
> ELF    60820000-60944000    Deferred        shell32<elf>
>   \-PE    60830000-60944000    \               shell32
> ELF    60944000-609a3000    Deferred        shlwapi<elf>
>   \-PE    60950000-609a3000    \               shlwapi
> ELF    609a3000-60a52000    Deferred        comdlg32<elf>
>   \-PE    609b0000-60a52000    \               comdlg32
> ELF    60a52000-60ae9000    Export          winmm<elf>
>   \-PE    60a60000-60ae9000    \               winmm
> ELF    60b9f000-60c3f000    Deferred        winex11<elf>
>   \-PE    60bb0000-60c3f000    \               winex11
> ELF    60d79000-60d7b000    Deferred        libxcb-xlib.so.0
> ELF    60d7b000-60d97000    Deferred        libxcb.so.1
> ELF    60da0000-60da5000    Deferred        libxxf86vm.so.1
> ELF    60dc7000-60dfa000    Deferred        uxtheme<elf>
>   \-PE    60dd0000-60dfa000    \               uxtheme
> ELF    60dfa000-60e34000    Deferred        libcups.so.2
> ELF    60f2b000-60fa9000    Deferred        libgnutls.so.13
> ELF    60ffb000-6100c000    Deferred        libtasn1.so.3
> ELF    6100c000-6107b000    Deferred        libgcrypt.so.11
> ELF    6107b000-6107f000    Deferred        libgpg-error.so.0
> ELF    6109b000-610d2000    Deferred        winealsa<elf>
>   \-PE    610a0000-610d2000    \               winealsa
> ELF    610d2000-611b4000    Deferred        libasound.so.2
> ELF    611be000-611d6000    Deferred        msacm32<elf>
>   \-PE    611c0000-611d6000    \               msacm32
> ELF    611d6000-611ff000    Deferred        msacm32<elf>
>   \-PE    611e0000-611ff000    \               msacm32
> ELF    611ff000-61214000    Deferred        midimap<elf>
>   \-PE    61200000-61214000    \               midimap
> ELF    61214000-61227000    Deferred        olepro32<elf>
>   \-PE    61220000-61227000    \               olepro32
> ELF    61227000-61255000    Deferred        d3d8<elf>
>   \-PE    61230000-61255000    \               d3d8
> ELF    61255000-61383000    Deferred        wined3d<elf>
>   \-PE    61270000-61383000    \               wined3d
> ELF    61383000-613d1000    Export          dsound<elf>
>   \-PE    61390000-613d1000    \               dsound
> ELF    613d1000-613e4000    Deferred        security<elf>
>   \-PE    613e0000-613e4000    \               security
> ELF    613e4000-6140b000    Deferred        netapi32<elf>
>   \-PE    613f0000-6140b000    \               netapi32
> ELF    6140b000-61439000    Deferred        ws2_32<elf>
>   \-PE    61410000-61439000    \               ws2_32
> ELF    61439000-6148b000    Deferred        wininet<elf>
>   \-PE    61440000-6148b000    \               wininet
> ELF    6148b000-614ae000    Deferred        mpr<elf>
>   \-PE    61490000-614ae000    \               mpr
> ELF    614ae000-61524000    Deferred        crypt32<elf>
>   \-PE    614c0000-61524000    \               crypt32
> ELF    61524000-61567000    Deferred        urlmon<elf>
>   \-PE    61530000-61567000    \               urlmon
> ELF    61567000-61585000    Deferred        mscms<elf>
>   \-PE    61570000-61585000    \               mscms
> ELF    61585000-615bd000    Deferred        liblcms.so.1
> ELF    615bd000-615ff000    Deferred        shdocvw<elf>
>   \-PE    615c0000-615ff000    \               shdocvw
> ELF    63ef9000-63f05000    Deferred        libnss_files.so.2
> ELF    66685000-66699000    Deferred        lz32<elf>
>   \-PE    66690000-66699000    \               lz32
> ELF    6c32d000-6c3d5000    Deferred        gdi32<elf>
>   \-PE    6c340000-6c3d5000    \               gdi32
> ELF    6c3e1000-6c53d000    Deferred        user32<elf>
>   \-PE    6c400000-6c53d000    \               user32
> ELF    6fbfd000-6fc34000    Deferred        winspool<elf>
>   \-PE    6fc00000-6fc34000    \               winspool
> ELF    735b3000-736af000    Deferred        oleaut32<elf>
>   \-PE    735d0000-736af000    \               oleaut32
> ELF    73903000-7392c000    Deferred        secur32<elf>
>   \-PE    73910000-7392c000    \               secur32
> ELF    7bf00000-7bf03000    Deferred        <wine-loader>
> Threads:
> process  tid      prio (all id:s are in hex)
> 00000008 (D) C:\Program Files\QIP\qip.exe
>     0000001c   15 <==
>     0000001b    0
>     0000001a    0
>     00000019    0
>     00000018    0
>     00000009    0
> 0000000c
>     00000014    0
>     00000013    0
>     00000012    0
>     0000000e    0
>     0000000d    0
> 0000000f
>     00000015    0
>     00000011    0
>     00000010    0
> 00000016
>     00000017    0
> Backtrace:
> =>1 0x60000812 (0x7db9e74c)
>   2 0x6019a028 (0x7db9e874)
>   3 0x6019157e (0x7db9e8b8)
>   4 0x613afc86 DSOUND_timer+0x1336() in dsound (0x7db9e9a8)
>   5 0x60a88bc8 in winmm (+0x28bc8) (0x7db9ea18)
>   6 0x603471fe call_thread_entry_point+0xe() in ntdll (0x7db9ea28)
>   7 0x60348832 in ntdll (+0x58832) (0x7db9eac8)
>   8 0x60348a2d in ntdll (+0x58a2d) (0x7db9f3b8)
>   9 0x6015b32f (0x7db9f4b8)
>
Ok, got pulseaudio to work, but it causes the same problem - sound 
becomes mega glitchy everywhere. So looks like even if driver doesn't 
crash the system, playback is still unstable and can become glitchy. 
Also I can not make Fedora 9 to load snd-sbxfi automatically. It ignores 
modprobe.conf and pulseudio does not detect snd-sbxfi as driver for my card.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Sat, 25 Oct 2008 21:40:40 +0100,
Jason Harvey wrote:
> 
> Takashi Iwai wrote:
> > At Sat, 25 Oct 2008 21:42:55 +0200,
> > Thomas Scheunemann wrote:
> >   
> >>> My solution is to use roundup_pow_of_two() instead of the own
> >>> funciton.  This should work better in general.
> >>>       
> >> I certainly agree that it is better to use an already defined function
> >> instead of reinventing the wheel.
> >>
> >>     
> >>> Anyway, I updated the repo (and rebased, sorry), updated the snapshot,
> >>> too.
> >>>       
> >> But this new version causes an immediate reboot on my machine even with
> >> the previously working speaker-test. If I interpret linux/log2.h correctly
> >> the desired function should be order_base_2 instead of roundup_pow_of_two.
> >> At least it works for me after that exchange.
> >>     
> >
> > Oh my.  You're right, it must be order_base_2(), of course.
> > I was too hurry to fix a bug after the server crash :)
> >
> > Now fixed and updated.  Thanks!
> >   
> Latest unstable (25Oct 19:57) works from command line with mplayer, 
> without the proc oss fix.
> aplay still works but only with dmix.

Do you have no sound quality problem with dmix like other people?

> Now also almost working in gnome with pulse, sound is recognisable but 
> with lots of interference/corruption.

What about base_rate=48000 option?

> Machine did not crash at any point!

Heh, finally.

> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says 
> 2.6.25 or earlier?

You can ignore what stated in SUPPORTED_KERNELS.
It's just an excuse not to support vendor kernels.  Distro vendor
kernels are often way too modified to support properly by the
out-of-tree driver.

FWIW, the current alsa-driver (and unstable) snapshot should work fine
with up to 2.6.28-rc1 kernel.  sbxfi is marked to be available on
2.6.25 or later kernels.  It won't be built for earlier kernels.


thanks,

Takashi

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Sat, 25 Oct 2008 23:57:53 +0200,
Bjoern Olausson wrote:
> 
> > Latest unstable (25Oct 19:57) works from command line with mplayer,
> > without the proc oss fix.
> >
> Confirmed.
> The stuttering got better, but is still present.

Hm.  The probme like stuttering is a bit hard to analyze.
In most cases, it comes from the inaccurate PCM hwptr (i.e. the value
calculated in PCM pointer callback is wrong), but not always like
that.

> Xine works flawless.
> 
> > aplay still works but only with dmix.
> >
> Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
> bit scratchy..

To be sure - this symptom is only on sbxfi, right?

> All other common samplingrates work flawless. Could someone confirm that?
> http://tmp.olausson.de/30days/0_16_s_8000.wav
> http://tmp.olausson.de/30days/0_16_s_11025.wav
> http://tmp.olausson.de/30days/0_16_s_96000.wav
> 
> Just using "aplay file.wav"
> 
> More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz
> "mplayer file.wav"
> 
> mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.

Yes, please...

> > Now also almost working in gnome with pulse, sound is recognisable but
> > with lots of interference/corruption.
> >
> No pulseaudio on my machine. Sry.
> 
> > Machine did not crash at any point!
> >
> Just observed a X crash when using smplayer to play a avi. When I
> closed smplayer while the movie was playing X crashed. (But could be
> unrelated to audio, I could not reproduce it)

I'm not sure whether this is really related with sbxfi.
For checking that, you can load snd-dummy driver instead, and run
smplayer with it.

> But no crash or freez so far.
> 
> > This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
> > 2.6.25 or earlier?
> >
> I am using vanilla 2.6.27.3
> 
> Thanks for you awesome work!
> 
> By the way, what's next on your plan when stereo output and recording
> is working flawless?

A few important features are in my mind:
- continuous rate support
- multi-channel playback
- multi-stream playback

Not sure whether I can achieve any of them without a document,
though.


thanks,

Takashi

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Sun, 26 Oct 2008 09:32:08 +0300,
The Source wrote:
> 
> Bjoern Olausson пишет:
> >> Latest unstable (25Oct 19:57) works from command line with mplayer,
> >> without the proc oss fix.
> >>
> >>     
> > Confirmed.
> > The stuttering got better, but is still present.
> >
> > Xine works flawless.
> >
> >   
> >> aplay still works but only with dmix.
> >>
> >>     
> > Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
> > bit scratchy..
> > All other common samplingrates work flawless. Could someone confirm that?
> > http://tmp.olausson.de/30days/0_16_s_8000.wav
> > http://tmp.olausson.de/30days/0_16_s_11025.wav
> > http://tmp.olausson.de/30days/0_16_s_96000.wav
> >
> > Just using "aplay file.wav"
> >
> > More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz
> > "mplayer file.wav"
> >
> > mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
> >
> >   
> >> Now also almost working in gnome with pulse, sound is recognisable but
> >> with lots of interference/corruption.
> >>
> >>     
> > No pulseaudio on my machine. Sry.
> >
> >   
> >> Machine did not crash at any point!
> >>
> >>     
> > Just observed a X crash when using smplayer to play a avi. When I
> > closed smplayer while the movie was playing X crashed. (But could be
> > unrelated to audio, I could not reproduce it)
> >
> > But no crash or freez so far.
> >
> >   
> >> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
> >> 2.6.25 or earlier?
> >>
> >>     
> > I am using vanilla 2.6.27.3
> >
> > Thanks for you awesome work!
> >
> > By the way, what's next on your plan when stereo output and recording
> > is working flawless?
> >
> >
> > kind regards
> > Bjoern
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> >   
> Tried the latest driver.
> All is fine (haven't tested recording however) except pulseaudio 
> (doesn't work) and wine (sound is mega-glitchy, possibly because of 
> strange period and buffer sizes it uses: period=544, buffer=8704). 

Maybe due to the sample rate?  I guess with 48kHz it would be a more
sane period/buffer size.


thanks,

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

Re: Backported sbxfi driver. Pulse works!

[Jason Harvey]

Takashi Iwai wrote:
> At Sat, 25 Oct 2008 21:40:40 +0100,
> Jason Harvey wrote:
>   
>> Latest unstable (25Oct 19:57) works from command line with mplayer, 
>> without the proc oss fix.
>> aplay still works but only with dmix.
>>     
>
> Do you have no sound quality problem with dmix like other people?
>   
No dmix trouble when I run "aplay -Dplug:dmix:0 wn.wav" produces perfect 
sound. Wav is three minutes long and it was 100% ok throughout.

>   
>> Now also almost working in gnome with pulse, sound is recognisable but 
>> with lots of interference/corruption.
>>     
>
> What about base_rate=48000 option?
>   
Genius! It is now working through pulse PERFECTLY.
Have two instances of mplayer playing right this second.
Can hear both tracks playing without any trouble.

I just edited one line in /etc/pulse/daemon.conf not sure it is the 
option you were talking about above but it works for me!

Will put the card into my 64bit main machine in a minute and try it there :)

Jason

Re: Backported sbxfi driver, possible fix

[The Source]

Takashi Iwai пишет:
> At Sun, 26 Oct 2008 09:32:08 +0300,
> The Source wrote:
>   
>> Bjoern Olausson пишет:
>>     
>>>> Latest unstable (25Oct 19:57) works from command line with mplayer,
>>>> without the proc oss fix.
>>>>
>>>>     
>>>>         
>>> Confirmed.
>>> The stuttering got better, but is still present.
>>>
>>> Xine works flawless.
>>>
>>>   
>>>       
>>>> aplay still works but only with dmix.
>>>>
>>>>     
>>>>         
>>> Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
>>> bit scratchy..
>>> All other common samplingrates work flawless. Could someone confirm that?
>>> http://tmp.olausson.de/30days/0_16_s_8000.wav
>>> http://tmp.olausson.de/30days/0_16_s_11025.wav
>>> http://tmp.olausson.de/30days/0_16_s_96000.wav
>>>
>>> Just using "aplay file.wav"
>>>
>>> More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz
>>> "mplayer file.wav"
>>>
>>> mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
>>>
>>>   
>>>       
>>>> Now also almost working in gnome with pulse, sound is recognisable but
>>>> with lots of interference/corruption.
>>>>
>>>>     
>>>>         
>>> No pulseaudio on my machine. Sry.
>>>
>>>   
>>>       
>>>> Machine did not crash at any point!
>>>>
>>>>     
>>>>         
>>> Just observed a X crash when using smplayer to play a avi. When I
>>> closed smplayer while the movie was playing X crashed. (But could be
>>> unrelated to audio, I could not reproduce it)
>>>
>>> But no crash or freez so far.
>>>
>>>   
>>>       
>>>> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
>>>> 2.6.25 or earlier?
>>>>
>>>>     
>>>>         
>>> I am using vanilla 2.6.27.3
>>>
>>> Thanks for you awesome work!
>>>
>>> By the way, what's next on your plan when stereo output and recording
>>> is working flawless?
>>>
>>>
>>> kind regards
>>> Bjoern
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
>>>   
>>>       
>> Tried the latest driver.
>> All is fine (haven't tested recording however) except pulseaudio 
>> (doesn't work) and wine (sound is mega-glitchy, possibly because of 
>> strange period and buffer sizes it uses: period=544, buffer=8704). 
>>     
>
> Maybe due to the sample rate?  I guess with 48kHz it would be a more
> sane period/buffer size.
>
>
> thanks,
>
> Takashi
>
>   
With that option pulseaudio works better (still some glitches, but very 
small). But wine still corrupts sound.

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

Re: Backported sbxfi driver, possible fix

[The Source]

Takashi Iwai пишет:
> At Sun, 26 Oct 2008 09:32:08 +0300,
> The Source wrote:
>   
>> Bjoern Olausson пишет:
>>     
>>>> Latest unstable (25Oct 19:57) works from command line with mplayer,
>>>> without the proc oss fix.
>>>>
>>>>     
>>>>         
>>> Confirmed.
>>> The stuttering got better, but is still present.
>>>
>>> Xine works flawless.
>>>
>>>   
>>>       
>>>> aplay still works but only with dmix.
>>>>
>>>>     
>>>>         
>>> Samplingrate 11025Hz and 8000Hz do not play a clear sinus, sounds a
>>> bit scratchy..
>>> All other common samplingrates work flawless. Could someone confirm that?
>>> http://tmp.olausson.de/30days/0_16_s_8000.wav
>>> http://tmp.olausson.de/30days/0_16_s_11025.wav
>>> http://tmp.olausson.de/30days/0_16_s_96000.wav
>>>
>>> Just using "aplay file.wav"
>>>
>>> More noticable ist it when using mplayer. Crackles a lot with 8000Hz and 11025Hz
>>> "mplayer file.wav"
>>>
>>> mmh, xine crackles too. Please someone confirm, otherwise the files may be bad.
>>>
>>>   
>>>       
>>>> Now also almost working in gnome with pulse, sound is recognisable but
>>>> with lots of interference/corruption.
>>>>
>>>>     
>>>>         
>>> No pulseaudio on my machine. Sry.
>>>
>>>   
>>>       
>>>> Machine did not crash at any point!
>>>>
>>>>     
>>>>         
>>> Just observed a X crash when using smplayer to play a avi. When I
>>> closed smplayer while the movie was playing X crashed. (But could be
>>> unrelated to audio, I could not reproduce it)
>>>
>>> But no crash or freez so far.
>>>
>>>   
>>>       
>>>> This was running on 2.6.26... is this a problem? SUPPORTED_KERNELS says
>>>> 2.6.25 or earlier?
>>>>
>>>>     
>>>>         
>>> I am using vanilla 2.6.27.3
>>>
>>> Thanks for you awesome work!
>>>
>>> By the way, what's next on your plan when stereo output and recording
>>> is working flawless?
>>>
>>>
>>> kind regards
>>> Bjoern
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
>>>   
>>>       
>> Tried the latest driver.
>> All is fine (haven't tested recording however) except pulseaudio 
>> (doesn't work) and wine (sound is mega-glitchy, possibly because of 
>> strange period and buffer sizes it uses: period=544, buffer=8704). 
>>     
>
> Maybe due to the sample rate?  I guess with 48kHz it would be a more
> sane period/buffer size.
>
>
> thanks,
>
> Takashi
>
>   
--With that option pulseaudio works better (still some glitches, but --very
--small). But wine still corrupts sound.

Hmmm....after sound got currupted, I started playing a file with xmms. 
Sound was horrible, but I couldn't get hw_params, because the contents 
of that file are 'closed'! How can this be if xmms uses alsa at that time??
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver, possible fix

[Alexander E. Patrakov]

Takashi Iwai wrote:
> A few important features are in my mind:
> - continuous rate support

In the sources, you have:

> Note: 44.1kHz is possible, but is more complex because it uses a method
> whereby the channel ring marks each sample in the channel ring as valid
> or not, so to get 44.1kHz, some samples are simply tagged invalid. The
> "channel ring" is not the ring buffer that is used to get sound samples
> to the card. The "channel ring" is used to pass samples between
> different processing modules on the card. One of these processing
> modules is the SRC, another is the INs/OUTs, another is the hardware
> mixer, and yet another is the DSP.

Do I understand correctly that the card internally resamples the sound 
to a different rate using the zero-order-hold method? If so, I'd rather 
not see this feature at all unless the "i_want_horrible_sound" parameter 
is passed, because software can do it better, and some program will 
surely default to using this hardware misfeature.

OTOH, Wine is doing this for ages and nobody except me complains 
(http://bugs.winehq.org/show_bug.cgi?id=14717)

-- 
Alexander E. Patrakov
(not an owner of any Creative card)

Re: Backported sbxfi driver, possible fix

[The Source]

Alexander E. Patrakov пишет:
> Takashi Iwai wrote:
>   
>> A few important features are in my mind:
>> - continuous rate support
>>     
>
> In the sources, you have:
>
>   
>> Note: 44.1kHz is possible, but is more complex because it uses a method
>> whereby the channel ring marks each sample in the channel ring as valid
>> or not, so to get 44.1kHz, some samples are simply tagged invalid. The
>> "channel ring" is not the ring buffer that is used to get sound samples
>> to the card. The "channel ring" is used to pass samples between
>> different processing modules on the card. One of these processing
>> modules is the SRC, another is the INs/OUTs, another is the hardware
>> mixer, and yet another is the DSP.
>>     
>
> Do I understand correctly that the card internally resamples the sound 
> to a different rate using the zero-order-hold method? If so, I'd rather 
> not see this feature at all unless the "i_want_horrible_sound" parameter 
> is passed, because software can do it better, and some program will 
> surely default to using this hardware misfeature.
>
> OTOH, Wine is doing this for ages and nobody except me complains 
> (http://bugs.winehq.org/show_bug.cgi?id=14717)
>
>   
Wine causes sound corruption with this driver for me (along with some 
other software like Pulseaudio).
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Mon, 27 Oct 2008 08:32:05 +0300,
The Source wrote:
> 
> Alexander E. Patrakov пишет:
> > Takashi Iwai wrote:
> >   
> >> A few important features are in my mind:
> >> - continuous rate support
> >>     
> >
> > In the sources, you have:
> >
> >   
> >> Note: 44.1kHz is possible, but is more complex because it uses a method
> >> whereby the channel ring marks each sample in the channel ring as valid
> >> or not, so to get 44.1kHz, some samples are simply tagged invalid. The
> >> "channel ring" is not the ring buffer that is used to get sound samples
> >> to the card. The "channel ring" is used to pass samples between
> >> different processing modules on the card. One of these processing
> >> modules is the SRC, another is the INs/OUTs, another is the hardware
> >> mixer, and yet another is the DSP.
> >>     
> >
> > Do I understand correctly that the card internally resamples the sound 
> > to a different rate using the zero-order-hold method? If so, I'd rather 
> > not see this feature at all unless the "i_want_horrible_sound" parameter 
> > is passed, because software can do it better, and some program will 
> > surely default to using this hardware misfeature.
> >
> > OTOH, Wine is doing this for ages and nobody except me complains 
> > (http://bugs.winehq.org/show_bug.cgi?id=14717)
> >
> >   
> Wine causes sound corruption with this driver for me (along with some 
> other software like Pulseaudio).

Does it happen also with base_rate=48000 option?

It'd be helpful if someone can summarize the working and non-working
cases.  For example,

global info:
1. sbxfi driver version (date & HEADs)
2. base_rate value
3. system details (x86-64, distro, kernel version, etc)

for each app:
A. Application name / version
B. working or not-working, problem descriptions
C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params)
D. period_size and buffer_size (ditto, or in kernel message)
E. any special options

Maybe also nice on Wiki...


thanks,

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

Re: Backported sbxfi driver, possible fix

[The Source]

Takashi Iwai пишет:
> At Mon, 27 Oct 2008 08:32:05 +0300,
> The Source wrote:
>   
>> Alexander E. Patrakov пишет:
>>     
>>> Takashi Iwai wrote:
>>>   
>>>       
>>>> A few important features are in my mind:
>>>> - continuous rate support
>>>>     
>>>>         
>>> In the sources, you have:
>>>
>>>   
>>>       
>>>> Note: 44.1kHz is possible, but is more complex because it uses a method
>>>> whereby the channel ring marks each sample in the channel ring as valid
>>>> or not, so to get 44.1kHz, some samples are simply tagged invalid. The
>>>> "channel ring" is not the ring buffer that is used to get sound samples
>>>> to the card. The "channel ring" is used to pass samples between
>>>> different processing modules on the card. One of these processing
>>>> modules is the SRC, another is the INs/OUTs, another is the hardware
>>>> mixer, and yet another is the DSP.
>>>>     
>>>>         
>>> Do I understand correctly that the card internally resamples the sound 
>>> to a different rate using the zero-order-hold method? If so, I'd rather 
>>> not see this feature at all unless the "i_want_horrible_sound" parameter 
>>> is passed, because software can do it better, and some program will 
>>> surely default to using this hardware misfeature.
>>>
>>> OTOH, Wine is doing this for ages and nobody except me complains 
>>> (http://bugs.winehq.org/show_bug.cgi?id=14717)
>>>
>>>   
>>>       
>> Wine causes sound corruption with this driver for me (along with some 
>> other software like Pulseaudio).
>>     
>
> Does it happen also with base_rate=48000 option?
>   
Yes.
> It'd be helpful if someone can summarize the working and non-working
> cases.  For example,
>
> global info:
> 1. sbxfi driver version (date & HEADs)
> 2. base_rate value
> 3. system details (x86-64, distro, kernel version, etc)
>
>   
26.10.2008 snapshot, don't remember the time.
96000 and 48000
x86-64 Fedora 9 kernel-2.6.26.6-79.fc9.x86_64
> for each app:
> A. Application name / version
> B. working or not-working, problem descriptions
> C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params)
> D. period_size and buffer_size (ditto, or in kernel message)
> E. any special options
>
>   
Wine 1.1.6
Sound glitches
Both ALSA and OSS
Very weird values, I reported before.
> Maybe also nice on Wiki...
>
>
> thanks,
>
> Takashi
>
>   

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

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Mon, 27 Oct 2008 10:15:07 +0500,
Alexander E. Patrakov wrote:
> 
> Takashi Iwai wrote:
> > A few important features are in my mind:
> > - continuous rate support
> 
> In the sources, you have:
> 
> > Note: 44.1kHz is possible, but is more complex because it uses a method
> > whereby the channel ring marks each sample in the channel ring as valid
> > or not, so to get 44.1kHz, some samples are simply tagged invalid. The
> > "channel ring" is not the ring buffer that is used to get sound samples
> > to the card. The "channel ring" is used to pass samples between
> > different processing modules on the card. One of these processing
> > modules is the SRC, another is the INs/OUTs, another is the hardware
> > mixer, and yet another is the DSP.
> 
> Do I understand correctly that the card internally resamples the sound 
> to a different rate using the zero-order-hold method? If so, I'd rather 
> not see this feature at all unless the "i_want_horrible_sound" parameter 
> is passed, because software can do it better, and some program will 
> surely default to using this hardware misfeature.

Likely it's a wrong guess.  emu20k1 has the following register bits.

# define SRCCTL_PITCH_ROM	(3<<11)	/* pitch ROM select */
#  define SRCCTL_PITCH_HIGH	(0<<11)	/* 0 to 8.0: very high quality */
#  define SRCCTL_PITCH_EXT_HIGH	(1<<11)	/* 0.26 to 1.72: extermely high qual.*/
#  define SRCCTL_PITCH_88kHZ	(2<<11)	/* 1.8375: 88.2kHz 48kHz */
#  define SRCCTL_PITCH_96KHZ	(3<<11) /* 2.0: 96kHz 48kHz */


Takashi

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Mon, 27 Oct 2008 09:34:27 +0300,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Mon, 27 Oct 2008 08:32:05 +0300,
> > The Source wrote:
> >   
> >> Alexander E. Patrakov пишет:
> >>     
> >>> Takashi Iwai wrote:
> >>>   
> >>>       
> >>>> A few important features are in my mind:
> >>>> - continuous rate support
> >>>>     
> >>>>         
> >>> In the sources, you have:
> >>>
> >>>   
> >>>       
> >>>> Note: 44.1kHz is possible, but is more complex because it uses a method
> >>>> whereby the channel ring marks each sample in the channel ring as valid
> >>>> or not, so to get 44.1kHz, some samples are simply tagged invalid. The
> >>>> "channel ring" is not the ring buffer that is used to get sound samples
> >>>> to the card. The "channel ring" is used to pass samples between
> >>>> different processing modules on the card. One of these processing
> >>>> modules is the SRC, another is the INs/OUTs, another is the hardware
> >>>> mixer, and yet another is the DSP.
> >>>>     
> >>>>         
> >>> Do I understand correctly that the card internally resamples the sound 
> >>> to a different rate using the zero-order-hold method? If so, I'd rather 
> >>> not see this feature at all unless the "i_want_horrible_sound" parameter 
> >>> is passed, because software can do it better, and some program will 
> >>> surely default to using this hardware misfeature.
> >>>
> >>> OTOH, Wine is doing this for ages and nobody except me complains 
> >>> (http://bugs.winehq.org/show_bug.cgi?id=14717)
> >>>
> >>>   
> >>>       
> >> Wine causes sound corruption with this driver for me (along with some 
> >> other software like Pulseaudio).
> >>     
> >
> > Does it happen also with base_rate=48000 option?
> >   
> Yes.
> > It'd be helpful if someone can summarize the working and non-working
> > cases.  For example,
> >
> > global info:
> > 1. sbxfi driver version (date & HEADs)
> > 2. base_rate value
> > 3. system details (x86-64, distro, kernel version, etc)
> >
> >   
> 26.10.2008 snapshot, don't remember the time.

Add prefix numbers (1, 2, 3) to each item.

See HEAD files in alsa-driver*/ and alsa-driver*/alsa-kernel, and take
the first line.

> 96000 and 48000
> x86-64 Fedora 9 kernel-2.6.26.6-79.fc9.x86_64
> > for each app:
> > A. Application name / version
> > B. working or not-working, problem descriptions
> > C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params)
> > D. period_size and buffer_size (ditto, or in kernel message)
> > E. any special options
> >
> >   
> Wine 1.1.6

Add prefix to each item, too.

> Sound glitches
> Both ALSA and OSS
> Very weird values, I reported before.

Write it up again.


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

Re: Backported sbxfi driver, possible fix

[James Courtier-Dutton]

Alexander E. Patrakov wrote:
> Takashi Iwai wrote:
> 
>> Note: 44.1kHz is possible, but is more complex because it uses a method
>> whereby the channel ring marks each sample in the channel ring as valid
>> or not, so to get 44.1kHz, some samples are simply tagged invalid. The
>> "channel ring" is not the ring buffer that is used to get sound samples
>> to the card. The "channel ring" is used to pass samples between
>> different processing modules on the card. One of these processing
>> modules is the SRC, another is the INs/OUTs, another is the hardware
>> mixer, and yet another is the DSP.
> 
> Do I understand correctly that the card internally resamples the sound 
> to a different rate using the zero-order-hold method? If so, I'd rather 
> not see this feature at all unless the "i_want_horrible_sound" parameter 
> is passed, because software can do it better, and some program will 
> surely default to using this hardware misfeature.
> 


Alex,

I added that comment (takashi cut and pasted my text). No resampling is
done.
Say you have a buffer that is running at 48kHz.
So you have say 480 samples at the 48kHz rate.
But if you want to transfer 44.1kHz rate samples over it, you only want
441 samples to be there, so what to do with the left over 39 samples.
What the xfi does is next to each sample it adds a "valid" tag.
So, the xfi adds those 39 samples but marks them as "invalid".
The xfi then drops the 39 "invalid" samples, leaving only the 441
"valid" samples just before sending them at 44.1kHz to the DAC.
Does this explain things a bit better.
FYI, the xfi actually works internally at 384kHz, so it is actually
marking a lot of samples as "invalid".

Kind Regards

James

Re: Backported sbxfi driver, possible fix

[Bjoern Olausson]

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

On Mon, Oct 27, 2008 at 07:28, Takashi Iwai <tiwai@suse.de> wrote:
> It'd be helpful if someone can summarize the working and non-working
> cases.  For example,
>
> global info:
> 1. sbxfi driver version (date & HEADs)
> 2. base_rate value
> 3. system details (x86-64, distro, kernel version, etc)
>
> for each app:
> A. Application name / version
> B. working or not-working, problem descriptions
> C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params)
> D. period_size and buffer_size (ditto, or in kernel message)
> E. any special options
>
> Maybe also nice on Wiki...
>
>
> thanks,
>
> Takashi
>

1. sbxfi driver version (date & HEADs)
	10/27/2008 05:55:00 PM

	./HEAD
	7d1c628613fa81595d145c897530e2eb0fbbf922 Merge commit 'stable/master'
	390dde1aeba0aec19bd121dfcb2147a1bc721756 jack - fix build with older kernels
	2e5fb80ee0cfed9c9ec4b977822b13d7a8d4790f Merge commit 'stable/master'
	d338c02cda2d5525e7ad3b35a2d51438c8fc8f08 x86 mach: test for
mach_apic.h to skip empty directories
	75b71fe1b618af2250692144205e71dede39aeb0 Merge commit 'stable/master'
	795b6cd7e0006e2c62a9c7004555b5b22c9e4329 alsa-info - Fix quoting
	8682b8b4ced855b01639d85098ca7de23db87c3d Merge branch 'topic/snd-hrtimer'
	46195d51d453ee7f1579028ba0407efafe03b3d4 snd-hrtimer - Add kernel
version dependency 2.6.24 or later
	058cbcd459dcfa90b40587932d4a2069497fa849 Merge branch 'topic/snd-hrtimer'
	8cadf99a5ca45aef2c4e7970e71bf1571163018d Merge branch 'topic/tools'

	./alsa-kernel/HEAD
	16fb0167b6a59608defbc164dad266613fae1fc5 Merge commit 'stable/master'
	58e5beb32b45cf7a09733886f600fe6442586cad Merge branch 'topic/fix/hda'
	e044c39ae258678d6ebb09fccb2a0fdf7ec51847 ALSA: hda - Restore default
pin configs for realtek codecs
	ec99a09ebe531c8d211b51d9e33d3a7341080e17 Merge branch 'topic/fix/misc'
	2f1e593d4209d0194f9639c5d11aa91171435963 sound: use a common working
email address
	07580a206c3755724fea57bc84a4a4064ee62c00 Merge commit 'stable/master'
	b69dffcb0a963ff7f0d9bad391c2c9bae37a837e Merge branch 'topic/hda-next'
	74aeaabc3e452b29bc1b9eac5aa48923569f8a4e ALSA: hda: add support for
jack detection on IDT codecs.
	50a9f7905fb3e6ae25e80ba443a14d878caef0c9 ALSA: hda: add
snd_hda_get_jack* functions
	282cd76ffca781013151344c4b0f9229e9ea3c35 ALSA: hda: dynamic jack id

2. base_rate value
	rate: 96000 (96000/1)

3. system details

	Gentoo Linux
	Portage 2.1.4.5 (default-linux/amd64/2007.0/desktop, gcc-4.1.2,
glibc-2.6.1-r0, 2.6.27.3-unpatched x86_64)
	=================================================================
	System uname: 2.6.27.3-unpatched x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
	Timestamp of tree: Sun, 26 Oct 2008 16:18:01 +0000
	distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port
3632) [disabled]


A)	MPlayer dev-SVN-r27725-4.1.2
B)	Working, but horrible, crackeling sound at samplingrate 11025Hz
22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200
(3200, 48000 and 96000 are fine)
	checked with WindowsXP. In XP the sound is nice and clear. So the
files are good.
C)	OSS (see bug-mplayer file)
D)	See bug-mplayer file
E)	nothing

A)	Xine 0.99.5
B)	No samplingrate is clear, all is crackeling....
C) 	ALSA I guess (bug-mplayer file)
D)	See bug-xine file
E)	nothing


So one wired thing:
I first tested mplayer... all samplingrates except 3200, 48000 and
96000 were bad.
Then I tested xine... everything was bad.
Then I tested mplayer again to dump the info into the files (bug-mplayer)
suddenly all samplerates were fine.... testing again and all went bad again?
But basically you can say everything is crapy right now.

Kind regards
Bjoern

[-- Attachment #2: bug-mplayer --]
[-- Type: application/octet-stream, Size: 2838 bytes --]

access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 4448
buffer_size: 8896
OSS format: S16_LE
OSS channels: 2
OSS rate: 11025
OSS period bytes: 2040
OSS periods: 2
OSS period frames: 4448
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 4448
buffer_size: 8896
OSS format: S16_LE
OSS channels: 2
OSS rate: 22050
OSS period bytes: 4084
OSS periods: 2
OSS period frames: 4448
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 6144
buffer_size: 12288
OSS format: S16_LE
OSS channels: 2
OSS rate: 32000
OSS period bytes: 8196
OSS periods: 2
OSS period frames: 6144
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 4448
buffer_size: 8896
OSS format: S16_LE
OSS channels: 2
OSS rate: 44056
OSS period bytes: 8168
OSS periods: 2
OSS period frames: 4448
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 4448
buffer_size: 8896
OSS format: S16_LE
OSS channels: 2
OSS rate: 44100
OSS period bytes: 8176
OSS periods: 2
OSS period frames: 4448
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 4160
buffer_size: 8320
OSS format: S16_LE
OSS channels: 2
OSS rate: 47250
OSS period bytes: 8192
OSS periods: 2
OSS period frames: 4160
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
OSS format: S16_LE
OSS channels: 2
OSS rate: 48000
OSS period bytes: 4096
OSS periods: 8
OSS period frames: 2048
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 1952
buffer_size: 15616
OSS format: S16_LE
OSS channels: 2
OSS rate: 50000
OSS period bytes: 4068
OSS periods: 8
OSS period frames: 1952
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 1952
buffer_size: 15616
OSS format: S16_LE
OSS channels: 2
OSS rate: 50400
OSS period bytes: 4100
OSS periods: 8
OSS period frames: 1952
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 6144
buffer_size: 12288
OSS format: S16_LE
OSS channels: 2
OSS rate: 8000
OSS period bytes: 2052
OSS periods: 2
OSS period frames: 6144
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 1120
buffer_size: 8960
OSS format: S16_LE
OSS channels: 2
OSS rate: 88200
OSS period bytes: 4116
OSS periods: 8
OSS period frames: 1120
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 1024
buffer_size: 16384
OSS format: S16_LE
OSS channels: 2
OSS rate: 96000
OSS period bytes: 4096
OSS periods: 16
OSS period frames: 1024

[-- Attachment #3: bug-xine --]
[-- Type: application/octet-stream, Size: 1512 bytes --]

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2048
buffer_size: 16384

[-- 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, possible fix

[Alexander E. Patrakov]

James Courtier-Dutton wrote:
> Alex,
> 
> I added that comment (takashi cut and pasted my text). No resampling is
> done.
> Say you have a buffer that is running at 48kHz.
> So you have say 480 samples at the 48kHz rate.
> But if you want to transfer 44.1kHz rate samples over it, you only want
> 441 samples to be there, so what to do with the left over 39 samples.
> What the xfi does is next to each sample it adds a "valid" tag.
> So, the xfi adds those 39 samples but marks them as "invalid".
> The xfi then drops the 39 "invalid" samples, leaving only the 441
> "valid" samples just before sending them at 44.1kHz to the DAC.
> Does this explain things a bit better?

Yes, thanks!

-- 
Alexander E. Patrakov

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Mon, 27 Oct 2008 07:28:51 +0100,
I wrote:
> 
> It'd be helpful if someone can summarize the working and non-working
> cases.  For example,
> 
> global info:

Forgot an important thing:

0. SBXFI model (product name, PCI ID, PCI SSID, cat /proc/asound/cards
   entry)


Takashi

> 1. sbxfi driver version (date & HEADs)
> 2. base_rate value
> 3. system details (x86-64, distro, kernel version, etc)
> 
> for each app:
> A. Application name / version
> B. working or not-working, problem descriptions
> C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params)
> D. period_size and buffer_size (ditto, or in kernel message)
> E. any special options
> 
> Maybe also nice on Wiki...
> 
> 
> thanks,
> 
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Tue, 28 Oct 2008 01:10:43 +0100,
Bjoern Olausson wrote:
> 
> On Mon, Oct 27, 2008 at 07:28, Takashi Iwai <tiwai@suse.de> wrote:
> > It'd be helpful if someone can summarize the working and non-working
> > cases.  For example,
> >
> > global info:
> > 1. sbxfi driver version (date & HEADs)
> > 2. base_rate value
> > 3. system details (x86-64, distro, kernel version, etc)
> >
> > for each app:
> > A. Application name / version
> > B. working or not-working, problem descriptions
> > C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params)
> > D. period_size and buffer_size (ditto, or in kernel message)
> > E. any special options
> >
> > Maybe also nice on Wiki...
> >
> >
> > thanks,
> >
> > Takashi
> >

Forgot to ask: which SBXFI model?  The product name, PCI ID, PCI SSID,
and /proc/asound/cards entry please.


> 2. base_rate value
> 	rate: 96000 (96000/1)

What about base_rate=48000?

BTW, I changed now base_rate to 48000 for testing as I got more
positive results with it.

> A)	MPlayer dev-SVN-r27725-4.1.2
> B)	Working, but horrible, crackeling sound at samplingrate 11025Hz
> 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200
> (3200, 48000 and 96000 are fine)
> 	checked with WindowsXP. In XP the sound is nice and clear. So the
> files are good.
> C)	OSS (see bug-mplayer file)
> D)	See bug-mplayer file
> E)	nothing

What if you do the following (as root)?

	# echo "mplayer 0 0 direct" > /proc/asound/card0/pcm0p/oss
	
This will disable the conversion in OSS emulation, so mplayer will
take 96kHz as is.

> A)	Xine 0.99.5
> B)	No samplingrate is clear, all is crackeling....
> C) 	ALSA I guess (bug-mplayer file)
> D)	See bug-xine file
> E)	nothing

Not sure about this...


Takashi

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Mon, 27 Oct 2008 20:08:04 +0000,
James Courtier-Dutton wrote:
> 
> Alexander E. Patrakov wrote:
> > Takashi Iwai wrote:
> > 
> >> Note: 44.1kHz is possible, but is more complex because it uses a method
> >> whereby the channel ring marks each sample in the channel ring as valid
> >> or not, so to get 44.1kHz, some samples are simply tagged invalid. The
> >> "channel ring" is not the ring buffer that is used to get sound samples
> >> to the card. The "channel ring" is used to pass samples between
> >> different processing modules on the card. One of these processing
> >> modules is the SRC, another is the INs/OUTs, another is the hardware
> >> mixer, and yet another is the DSP.
> > 
> > Do I understand correctly that the card internally resamples the sound 
> > to a different rate using the zero-order-hold method? If so, I'd rather 
> > not see this feature at all unless the "i_want_horrible_sound" parameter 
> > is passed, because software can do it better, and some program will 
> > surely default to using this hardware misfeature.
> > 
> 
> 
> Alex,
> 
> I added that comment (takashi cut and pasted my text). No resampling is
> done.
> Say you have a buffer that is running at 48kHz.
> So you have say 480 samples at the 48kHz rate.
> But if you want to transfer 44.1kHz rate samples over it, you only want
> 441 samples to be there, so what to do with the left over 39 samples.
> What the xfi does is next to each sample it adds a "valid" tag.
> So, the xfi adds those 39 samples but marks them as "invalid".
> The xfi then drops the 39 "invalid" samples, leaving only the 441
> "valid" samples just before sending them at 44.1kHz to the DAC.
> Does this explain things a bit better.
> FYI, the xfi actually works internally at 384kHz, so it is actually
> marking a lot of samples as "invalid".

Hm, so what is special about using 44.1kHz if many samples in the
audio-ring are already marked as invalid even with 48kHz?

It'd be helpful if you could provide a bit more information (or a
pseudo-code) for supporting non-48/96kHz samples.


thanks,

Takashi

Re: Backported sbxfi driver, possible fix

[Vedran Miletić]

But that surely isn't bitperfect, right?

2008/10/27 James Courtier-Dutton <James@superbug.co.uk>
> Alex,
>
> I added that comment (takashi cut and pasted my text). No resampling is
> done.
> Say you have a buffer that is running at 48kHz.
> So you have say 480 samples at the 48kHz rate.
> But if you want to transfer 44.1kHz rate samples over it, you only want
> 441 samples to be there, so what to do with the left over 39 samples.
> What the xfi does is next to each sample it adds a "valid" tag.
> So, the xfi adds those 39 samples but marks them as "invalid".
> The xfi then drops the 39 "invalid" samples, leaving only the 441
> "valid" samples just before sending them at 44.1kHz to the DAC.
> Does this explain things a bit better.
> FYI, the xfi actually works internally at 384kHz, so it is actually
> marking a lot of samples as "invalid".
>
> Kind Regards
>
> James
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>



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

Re: Backported sbxfi driver, possible fix

[Bjoern Olausson]

On Tue, Oct 28, 2008 at 08:14, Takashi Iwai <tiwai@suse.de> wrote:
>
> Forgot to ask: which SBXFI model?  The product name, PCI ID, PCI SSID,
> and /proc/asound/cards entry please.
>
01:00.0 0401: 1102:0005
        Subsystem: 1102:0021
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 21
        Region 0: I/O ports at 8c00 [size=32]
        Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M]
        Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Kernel driver in use: SB-XFi

01:00.0 Multimedia audio controller: Creative Labs SB X-Fi
        Subsystem: Creative Labs X-Fi Platinum
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 21
        Region 0: I/O ports at 8c00 [size=32]
        Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M]
        Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Kernel driver in use: SB-XFi


>
>> 2. base_rate value
>>       rate: 96000 (96000/1)
>
> What about base_rate=48000?
>
> BTW, I changed now base_rate to 48000 for testing as I got more
> positive results with it.
>
Should I pass this parameter during ./configure or as module parameter?

>> A)    MPlayer dev-SVN-r27725-4.1.2
>> B)    Working, but horrible, crackeling sound at samplingrate 11025Hz
>> 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200
>> (3200, 48000 and 96000 are fine)
>>       checked with WindowsXP. In XP the sound is nice and clear. So the
>> files are good.
>> C)    OSS (see bug-mplayer file)
>> D)    See bug-mplayer file
>> E)    nothing
>
> What if you do the following (as root)?
>
>        # echo "mplayer 0 0 direct" > /proc/asound/card0/pcm0p/oss
>
Tested... but gives only white noise, no matter what samplingrate or file....

> This will disable the conversion in OSS emulation, so mplayer will
> take 96kHz as is.
>
>> A)    Xine 0.99.5
>> B)    No samplingrate is clear, all is crackeling....
>> C)    ALSA I guess (bug-mplayer file)
>> D)    See bug-xine file
>> E)    nothing
>
> Not sure about this...
>
>
> Takashi
>

Bjoern

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Tue, 28 Oct 2008 14:48:01 +0100,
Bjoern Olausson wrote:
> 
> On Tue, Oct 28, 2008 at 08:14, Takashi Iwai <tiwai@suse.de> wrote:
> >
> > Forgot to ask: which SBXFI model?  The product name, PCI ID, PCI SSID,
> > and /proc/asound/cards entry please.
> >
> 01:00.0 0401: 1102:0005
>         Subsystem: 1102:0021
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes
>         Interrupt: pin A routed to IRQ 21
>         Region 0: I/O ports at 8c00 [size=32]
>         Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M]
>         Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M]
>         Capabilities: [40] Power Management version 2
>                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/0 Enable-
>                 Address: 0000000000000000  Data: 0000
>         Kernel driver in use: SB-XFi
> 
> 01:00.0 Multimedia audio controller: Creative Labs SB X-Fi
>         Subsystem: Creative Labs X-Fi Platinum
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes
>         Interrupt: pin A routed to IRQ 21
>         Region 0: I/O ports at 8c00 [size=32]
>         Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M]
>         Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M]
>         Capabilities: [40] Power Management version 2
>                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
> Queue=0/0 Enable-
>                 Address: 0000000000000000  Data: 0000
>         Kernel driver in use: SB-XFi
> 
> 
> >
> >> 2. base_rate value
> >>       rate: 96000 (96000/1)
> >
> > What about base_rate=48000?
> >
> > BTW, I changed now base_rate to 48000 for testing as I got more
> > positive results with it.
> >
> Should I pass this parameter during ./configure or as module parameter?

As a module parameter, either in somewhere modprobe.conf or such, or
via modprobe command line option.

I changed the latest version to use 48k as default, so you can just
grab the latest snapshot, too.

> >> A)    MPlayer dev-SVN-r27725-4.1.2
> >> B)    Working, but horrible, crackeling sound at samplingrate 11025Hz
> >> 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200
> >> (3200, 48000 and 96000 are fine)
> >>       checked with WindowsXP. In XP the sound is nice and clear. So the
> >> files are good.
> >> C)    OSS (see bug-mplayer file)
> >> D)    See bug-mplayer file
> >> E)    nothing
> >
> > What if you do the following (as root)?
> >
> >        # echo "mplayer 0 0 direct" > /proc/asound/card0/pcm0p/oss
> >
> Tested... but gives only white noise, no matter what samplingrate or file....

Weird.  What happens if you force to the sample rate to 48000 via
mplayer's option?


Takashi

Re: Backported sbxfi driver, possible fix

[Pavel Hofman]

James Courtier-Dutton wrote:
> Alexander E. Patrakov wrote:
> Alex,
> 
> I added that comment (takashi cut and pasted my text). No resampling is
> done.
> Say you have a buffer that is running at 48kHz.
> So you have say 480 samples at the 48kHz rate.
> But if you want to transfer 44.1kHz rate samples over it, you only want
> 441 samples to be there, so what to do with the left over 39 samples.
> What the xfi does is next to each sample it adds a "valid" tag.
> So, the xfi adds those 39 samples but marks them as "invalid".
> The xfi then drops the 39 "invalid" samples, leaving only the 441
> "valid" samples just before sending them at 44.1kHz to the DAC.
> Does this explain things a bit better.
> FYI, the xfi actually works internally at 384kHz, so it is actually
> marking a lot of samples as "invalid".
> 
> Kind Regards
> 
> James


James,

Thanks a lot for the info. Does it mean that the core runs at 384kHz, 
while codes are clocked by another clock signal PLL'd from the master 
clock to the required frequency? Theoretically this could allow running 
different outputs/channels at diferrent sample rates :)

Pavel.

Re: Backported sbxfi driver, possible fix

[Bjoern Olausson]

On Tue, Oct 28, 2008 at 15:12, Takashi Iwai <tiwai@suse.de> wrote:
> At Tue, 28 Oct 2008 14:48:01 +0100,
> Bjoern Olausson wrote:
>>
>> On Tue, Oct 28, 2008 at 08:14, Takashi Iwai <tiwai@suse.de> wrote:
>> >
>> > Forgot to ask: which SBXFI model?  The product name, PCI ID, PCI SSID,
>> > and /proc/asound/cards entry please.
>> >
>> 01:00.0 0401: 1102:0005
>>         Subsystem: 1102:0021
>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes
>>         Interrupt: pin A routed to IRQ 21
>>         Region 0: I/O ports at 8c00 [size=32]
>>         Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M]
>>         Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M]
>>         Capabilities: [40] Power Management version 2
>>                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>>         Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
>> Queue=0/0 Enable-
>>                 Address: 0000000000000000  Data: 0000
>>         Kernel driver in use: SB-XFi
>>
>> 01:00.0 Multimedia audio controller: Creative Labs SB X-Fi
>>         Subsystem: Creative Labs X-Fi Platinum
>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes
>>         Interrupt: pin A routed to IRQ 21
>>         Region 0: I/O ports at 8c00 [size=32]
>>         Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M]
>>         Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M]
>>         Capabilities: [40] Power Management version 2
>>                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>>         Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
>> Queue=0/0 Enable-
>>                 Address: 0000000000000000  Data: 0000
>>         Kernel driver in use: SB-XFi
>>
>>
>> >
>> >> 2. base_rate value
>> >>       rate: 96000 (96000/1)
>> >
>> > What about base_rate=48000?
>> >
>> > BTW, I changed now base_rate to 48000 for testing as I got more
>> > positive results with it.
>> >
>> Should I pass this parameter during ./configure or as module parameter?
>
> As a module parameter, either in somewhere modprobe.conf or such, or
> via modprobe command line option.
>
> I changed the latest version to use 48k as default, so you can just
> grab the latest snapshot, too.
>
>> >> A)    MPlayer dev-SVN-r27725-4.1.2
>> >> B)    Working, but horrible, crackeling sound at samplingrate 11025Hz
>> >> 22050Hz 44056 44100 47250 5000(less than the others) 50400 8000 88200
>> >> (3200, 48000 and 96000 are fine)
>> >>       checked with WindowsXP. In XP the sound is nice and clear. So the
>> >> files are good.
>> >> C)    OSS (see bug-mplayer file)
>> >> D)    See bug-mplayer file
>> >> E)    nothing
>> >
>> > What if you do the following (as root)?
>> >
>> >        # echo "mplayer 0 0 direct" > /proc/asound/card0/pcm0p/oss
>> >
>> Tested... but gives only white noise, no matter what samplingrate or file....
>
> Weird.  What happens if you force to the sample rate to 48000 via
> mplayer's option?
>
>
> Takashi
>

Sry for the delayed testing, but my "Diplomarbeit" has to be finish on
Monday... so I am a bit in a hurry...

But anyway:

Tested 10/30/2008 07:05:00 AM
712e4debd7b0c84ee68342cdc56ae8bdb0119b75 Merge commit 'stable/master'
0f6ba093f8aa7a9e2caff2a697edcfeaddd4e0a1 Remove __attribute__ form
dev_set_name() wrapper
1aec09cd650c40b93eb1956ff8396e61a52ccef3 Merge commit 'stable/master'
277a3f5f74b6ff1f7cb719f7bfbb2ccdde252cf2 Add dev_name() and
dev_set_name() wrappers
e3d42c6eae1ea6d43af6223d9338adf75e63f841 Merge branch 'topic/tools'
ff936f865a57e68289d6bd4b8da74670bf04a378 Remove topic/snd-hrtimer branch
1bf544cf592b7c2270ba1c28e67067d9c244e0e9 Merge commit 'stable/master'
d9aebb8d6130d1fc33a9ac4be62550914b2b0559 Merge branch 'topic/snd-hrtimer'
4f169e7e1cfa7a85e15920cda84eb7a8e80acf81 Add snd-hrtimer build stub
f5d186ece18e1b0b992ccb870827a6b618c6c6df Merge commit 'stable/master'


First the good news:
mplayer does play all samplerates very clear! Pure, lovely sinus ;-)
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384
OSS format: S16_LE
OSS channels: 2
OSS rate: 48000
OSS period bytes: 4096
OSS periods: 16
OSS period frames: 1024


Now the bad:

Xine does not work... crackles horrible on all sample rates when run from cmd:
xine 0_16_m_11025.wav

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 2048
buffer_size: 16384

kind regards
Bjoern

Re: Backported sbxfi driver, possible fix

[Bjoern Olausson]

On Thu, Oct 30, 2008 at 11:46, Bjoern Olausson <lkmlist@gmail.com> wrote:
> On Tue, Oct 28, 2008 at 15:12, Takashi Iwai <tiwai@suse.de> wrote:
>
>
> Now the bad:
>
> Xine does not work... crackles horrible on all sample rates when run from cmd:
> xine 0_16_m_11025.wav
>
> access: MMAP_INTERLEAVED
> format: S16_LE
> subformat: STD
> channels: 2
> rate: 48000 (48000/1)
> period_size: 2048
> buffer_size: 16384
>
> kind regards
> Bjoern
>

mmh, I recompiled xine-lib without mmap support but I still get
access: MMAP_INTERLEAVED

could mmap be a problem?

kind regards
Bjoern

Re: Backported sbxfi driver, possible fix

[Takashi Iwai]

At Thu, 30 Oct 2008 12:05:12 +0100,
Bjoern Olausson wrote:
> 
> On Thu, Oct 30, 2008 at 11:46, Bjoern Olausson <lkmlist@gmail.com> wrote:
> > On Tue, Oct 28, 2008 at 15:12, Takashi Iwai <tiwai@suse.de> wrote:
> >
> >
> > Now the bad:
> >
> > Xine does not work... crackles horrible on all sample rates when run from cmd:
> > xine 0_16_m_11025.wav
> >
> > access: MMAP_INTERLEAVED
> > format: S16_LE
> > subformat: STD
> > channels: 2
> > rate: 48000 (48000/1)
> > period_size: 2048
> > buffer_size: 16384
> >
> > kind regards
> > Bjoern
> >
> 
> mmh, I recompiled xine-lib without mmap support but I still get
> access: MMAP_INTERLEAVED

Maybe it's accessed via alsa-plugin.  What about let xine using
"hw" PCM device instead of "default"?  Then xine would play at 48kHz
natively without conversions in alsa-lib.

> could mmap be a problem?

Possible, can't determine exactly at this moment...


Takashi

Re: Backported sbxfi driver, possible fix

[Bjoern Olausson]

On Thu, Oct 30, 2008 at 12:07, Takashi Iwai <tiwai@suse.de> wrote:
> At Thu, 30 Oct 2008 12:05:12 +0100,
> Bjoern Olausson wrote:
>>
>> On Thu, Oct 30, 2008 at 11:46, Bjoern Olausson <lkmlist@gmail.com> wrote:
>> > On Tue, Oct 28, 2008 at 15:12, Takashi Iwai <tiwai@suse.de> wrote:
>> >
>> >
>> > Now the bad:
>> >
>> > Xine does not work... crackles horrible on all sample rates when run from cmd:
>> > xine 0_16_m_11025.wav
>> >
>> > access: MMAP_INTERLEAVED
>> > format: S16_LE
>> > subformat: STD
>> > channels: 2
>> > rate: 48000 (48000/1)
>> > period_size: 2048
>> > buffer_size: 16384
>> >
>> > kind regards
>> > Bjoern
>> >
>>
>> mmh, I recompiled xine-lib without mmap support but I still get
>> access: MMAP_INTERLEAVED
>
> Maybe it's accessed via alsa-plugin.  What about let xine using
> "hw" PCM device instead of "default"?  Then xine would play at 48kHz
> natively without conversions in alsa-lib.
>

mmh weird... xine works...
Couldn't reproduce my previous report... thought I changed nothing...
Please ignore the xine crackeling... seems not reproducable (If I can
reproduce it, I'll let you know).

Bjoern

problems with fedora 11 and pulseaudio and svn x-fi driver

[Ted T. Logan]

Hello,

I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and
installed it for the x-fi driver.

The problem is, with pulseaudio, i get a pop every few seconds
like, every 3 seconds, "pop" and it does it over and over and over

I seem to get no sound at all with the card if I bypass pulse

What can I do?

Re: problems with fedora 11 and pulseaudio and svn x-fi driver

[Ted T. Logan]

I killed pulseaudio and the problem is the same as far as every few
seconds, just a different sound.  it seems to be the xfi driver.

I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz
however, I am trying to get away from that driver because of other
issues.

Thanks!

On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:

> Hello,
> 
> I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and
> installed it for the x-fi driver.
> 
> The problem is, with pulseaudio, i get a pop every few seconds
> like, every 3 seconds, "pop" and it does it over and over and over
> 
> I seem to get no sound at all with the card if I bypass pulse
> 
> What can I do?
> 
> 

Re: problems with fedora 11 and pulseaudio and svn x-fi driver

[Takashi Iwai]

At Wed, 10 Jun 2009 03:52:35 -0500,
Ted T. Logan wrote:
> 
> I killed pulseaudio and the problem is the same as far as every few seconds,
> just a different sound.  it seems to be the xfi driver.

Please be more specific, what apps did you test and how, and on which
hardware, with which alsa-driver.  There is no svn alsa-driver at
all, at least, as I know of.

If it's emu20k1 chip (not emu20k2), try use_system_timer=1 module
option snd-ctxfi driver.  This will take the timer management back to
the old one using the system timer.


thanks,

Takashi

> I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz
> however, I am trying to get away from that driver because of other issues.
> 
> Thanks!
> 
> On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
> 
>     Hello,
>    
>     I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and
>     installed it for the x-fi driver.
>    
>     The problem is, with pulseaudio, i get a pop every few seconds
>     like, every 3 seconds, "pop" and it does it over and over and over
>    
>     I seem to get no sound at all with the card if I bypass pulse
>    
>     What can I do?
> 
> 

Re: problems with fedora 11 and pulseaudio and svn x-fi driver

[Ted T. Logan]

Sorry:
ftp://kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.bz2

Every app I've tried it with:)

Sound Blaster X-Fi SB0670 PCI Sound Card with emu20k1 chipset.


On Wed, 2009-06-10 at 11:29 +0200, Takashi Iwai wrote:

> At Wed, 10 Jun 2009 03:52:35 -0500,
> Ted T. Logan wrote:
> > 
> > I killed pulseaudio and the problem is the same as far as every few seconds,
> > just a different sound.  it seems to be the xfi driver.
> 
> Please be more specific, what apps did you test and how, and on which
> hardware, with which alsa-driver.  There is no svn alsa-driver at
> all, at least, as I know of.
> 
> If it's emu20k1 chip (not emu20k2), try use_system_timer=1 module
> option snd-ctxfi driver.  This will take the timer management back to
> the old one using the system timer.
> 
> 
> thanks,
> 
> Takashi
> 
> > I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz
> > however, I am trying to get away from that driver because of other issues.
> > 
> > Thanks!
> > 
> > On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
> > 
> >     Hello,
> >    
> >     I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and
> >     installed it for the x-fi driver.
> >    
> >     The problem is, with pulseaudio, i get a pop every few seconds
> >     like, every 3 seconds, "pop" and it does it over and over and over
> >    
> >     I seem to get no sound at all with the card if I bypass pulse
> >    
> >     What can I do?
> > 
> > 

Re: problems with fedora 11 and pulseaudio and svn x-fi driver

[Ted T. Logan]

same problem after I added those options.  I'm listening to something in
flash player right now and I have a click every 3 seconds.

On Wed, 2009-06-10 at 11:29 +0200, Takashi Iwai wrote:

> At Wed, 10 Jun 2009 03:52:35 -0500,
> Ted T. Logan wrote:
> > 
> > I killed pulseaudio and the problem is the same as far as every few seconds,
> > just a different sound.  it seems to be the xfi driver.
> 
> Please be more specific, what apps did you test and how, and on which
> hardware, with which alsa-driver.  There is no svn alsa-driver at
> all, at least, as I know of.
> 
> If it's emu20k1 chip (not emu20k2), try use_system_timer=1 module
> option snd-ctxfi driver.  This will take the timer management back to
> the old one using the system timer.
> 
> 
> thanks,
> 
> Takashi
> 
> > I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz
> > however, I am trying to get away from that driver because of other issues.
> > 
> > Thanks!
> > 
> > On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
> > 
> >     Hello,
> >    
> >     I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and
> >     installed it for the x-fi driver.
> >    
> >     The problem is, with pulseaudio, i get a pop every few seconds
> >     like, every 3 seconds, "pop" and it does it over and over and over
> >    
> >     I seem to get no sound at all with the card if I bypass pulse
> >    
> >     What can I do?
> > 
> > 

Re: problems with fedora 11 and pulseaudio and svn x-fi driver

[Ted T. Logan]

Here's the output during some skipping.  It happens with or without
pulse if I have any application playing sound to my xfi.  Do not have
the same problem if output goes to integrated intel:


cat /proc/asound/card0/pcm0p/sub0/* 
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 44100 (44100/1)
period_size: 32768
buffer_size: 65536
card: 0
device: 0
subdevice: 0
stream: PLAYBACK
id: ctxfi
name: Front/WaveIn
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 8
subdevices_avail: 7
128
128
state: RUNNING
trigger_time: 74684.238387841
tstamp : 74702.900700135
delay : 2664
avail : 62872
avail_max : 62872
-----
hw_ptr : 822976
appl_ptr : 825640
tstamp_mode: ENABLE
period_step: 1
avail_min: 63069
start_threshold: 4294967295
stop_threshold: 1073741824
silence_threshold: 0
silence_size: 0
boundary: 1073741824

On Wed, 2009-06-10 at 11:29 +0200, Takashi Iwai wrote:

> At Wed, 10 Jun 2009 03:52:35 -0500,
> Ted T. Logan wrote:
> > 
> > I killed pulseaudio and the problem is the same as far as every few seconds,
> > just a different sound.  it seems to be the xfi driver.
> 
> Please be more specific, what apps did you test and how, and on which
> hardware, with which alsa-driver.  There is no svn alsa-driver at
> all, at least, as I know of.
> 
> If it's emu20k1 chip (not emu20k2), try use_system_timer=1 module
> option snd-ctxfi driver.  This will take the timer management back to
> the old one using the system timer.
> 
> 
> thanks,
> 
> Takashi
> 
> > I did not have this problem with XFiDrv_Linux_Public_US_1.00.tar.gz
> > however, I am trying to get away from that driver because of other issues.
> > 
> > Thanks!
> > 
> > On Wed, 2009-06-10 at 03:39 -0500, Ted T. Logan wrote:
> > 
> >     Hello,
> >    
> >     I upgraded to fedora 11 with PA 9.15 and got the svn alsa-driver and
> >     installed it for the x-fi driver.
> >    
> >     The problem is, with pulseaudio, i get a pop every few seconds
> >     like, every 3 seconds, "pop" and it does it over and over and over
> >    
> >     I seem to get no sound at all with the card if I bypass pulse
> >    
> >     What can I do?
> > 
> > 

"ticks" with latest x-fi driver

[Ted T. Logan]

Hello,

I do not have this problem with:

XFiDrv_Linux_Public_US_1.00.tar.gz

but I tried the latest driver from:

ftp://kernel.org/pub/linux/kernel/people/tiwai/snapshot/

and I get a "tick" every second or two during playback with ANY
application.

Fedora 11.  sb0670 emu20k1.

What to do?