At Thu, 09 Oct 2008 20:50:52 +0100, James Courtier-Dutton wrote:

Takashi Iwai wrote:

...

Hi,

$SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches.

http://james.dutton.googlepages.com/home

There might be some extra info in the emu20k1.h file there. I do not have much time, but I will update the emu20k1.h file with any register info people need.

Great, I'll have a look later.

thanks,

Takashi

On Fri, 2008-10-10 at 08:01 +0200, Takashi Iwai wrote:

At Thu, 09 Oct 2008 15:17:58 -0500, Ted T. Logian wrote:

...

Sorry for the multiple posts, but once I rmmod snd-sbxfi, running mixer does fine. It seems if I have snd-sbxfi loaded and I run alsamixer, it locks the entire system.

So, do you mean loading the driver itself doesn't lock up? If so, it's better than I expected.

Did you run ever PCM playback/capture before that? This is more dangerous :)

Also, please give your hardware details, as there are different models for X-Fi, and some are handled pretty differently.

[BTW, please stop top-posting, and avoid HTML mails for ML. It's easy to switch to normal (plain) mail mode on Gmail, just a click.]

thanks,

Takashi

I think perhaps from uninstalling pulseaudio I got further. I can use mixer now, and it even has a "Master" device, but nothing else...

however, I do get a lock up later.

I get this from running aplay, too, if this helps...

aplay BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: [<c04fe489>] __list_add+0x6/0x4a *pde = 7c8a4067 Oops: 0000 [#1] SMP Modules linked in: bridge bnep rfcomm l2cap autofs4 sunrpc ipv6 nf_conntrack_ftp nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables fuse dm_mirror dm_log dm_mod snd_hda_intel snd_usb_audio snd_sbxfi pl2303 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq hci_usb bluetooth tuner_simple tuner_types snd_pcm_oss tda9887 snd_mixer_oss tda8290 snd_pcm snd_usb_lib snd_rawmidi snd_seq_device wm8775 gspca snd_timer cx25840 tuner nvidia(P) snd_page_alloc snd_hwdep sr_mod e100 usbserial cdrom snd soundcore i2c_i801 ivtv compat_ioctl32 i2c_algo_bit cx2341x v4l2_common tveeprom videodev pcspkr joydev iTCO_wdt iTCO_vendor_support i2c_core dcdbas v4l1_compat serio_raw mii sg ata_piix ata_generic pata_acpi libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]

Pid: 3031, comm: aplay Tainted: P (2.6.26.5-45.fc9.i686 #1) EIP: 0060:[<c04fe489>] EFLAGS: 00010046 CPU: 0 EIP is at __list_add+0x6/0x4a EAX: f7b9f1f8 EBX: f7b9f1f8 ECX: 00000000 EDX: f3de5138 ESI: f3de5100 EDI: f7b9f100 EBP: f7322de4 ESP: f7322de0 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process aplay (pid: 3031, ti=f7322000 task=f28abe80 task.ti=f7322000) Stack: f7b9f124 f7322dec c04fe4d7 f7322e00 f9cc32ee f28a1800 f7322e54 f709a910 f7322e14 f9cc338a 00000000 f7322e54 f709a910 f7322e28 f9baedc2 f70f9100 fffffff2 f709a800 f7322e64 f9baee9c f7322e54 00000000 f2847200 f709a920 Call Trace: [<c04fe4d7>] ? list_add+0xa/0xf [<f9cc32ee>] ? sbxfi_port_alloc+0x80/0x95 [snd_sbxfi] [<f9cc338a>] ? sbxfi_playback_open+0x13/0x82 [snd_sbxfi] [<f9baedc2>] ? snd_pcm_open_substream+0x3a/0x72 [snd_pcm] [<f9baee9c>] ? snd_pcm_open+0xa2/0x179 [snd_pcm] [<c0420db2>] ? default_wake_function+0x0/0xd [<f935a1b3>] ? snd_lookup_minor_data+0x3d/0x44 [snd] [<f9baefbf>] ? snd_pcm_playback_open+0x23/0x26 [snd_pcm] [<f935a4e3>] ? snd_open+0xc1/0x11e [snd] [<c0487c12>] ? chrdev_open+0x116/0x132 [<c0484178>] ? __dentry_open+0x10e/0x1fc [<c04842ed>] ? nameidata_to_filp+0x1f/0x33 [<c0487afc>] ? chrdev_open+0x0/0x132 [<c048f1ec>] ? do_filp_open+0x33e/0x6b0 [<f935a7fe>] ? snd_card_file_remove+0xce/0xd8 [snd] [<c0483ee8>] ? get_unused_fd_flags+0x64/0xc5 [<c0483f89>] ? do_sys_open+0x40/0xb6 [<c0484041>] ? sys_open+0x1e/0x26 [<c0404c32>] ? syscall_call+0x7/0xb [<c0630000>] ? down_read+0x27/0x29 ======================= Code: 6e c0 e8 cb 08 13 00 0f 0b 83 c4 0c eb fe 89 58 04 89 03 c7 42 04 00 02 20 00 c7 02 00 01 10 00 8b 5d fc c9 c3 55 89 e5 53 89 c3 <8b> 41 04 39 d0 74 14 51 50 52 68 f7 5a 6e c0 e8 93 08 13 00 0f EIP: [<c04fe489>] __list_add+0x6/0x4a SS:ESP 0068:f7322de0 ---[ end trace 0611fd70d756e2b7 ]--- Segmentation fault

Hi,

On Sat, 2008-10-11 at 19:41 +0200, Takashi Iwai wrote:

Could you build with XXX_CONST_TIMER defined? This will disable the adaptive timer-resolution handling I added to the driver, which doesn't exist in OSS sbxfi code at all.

No change in behaviour. It survives a little longer, but then the system hardlocks... without me even touching the keyboard even.

...

Noise is now on the right channel only.

Does it mean that the left channel plays normally as expected? Also, which sample rate are you using? I'm curious whether the sample rate tracking is correct...

No. The left channel is silent.

...

It might make more sense to poll for the DAC reset in the interrupt handler. I have noticed that the card generates an interrupt request

in

...

Windows once the DAC is online.

Interesting... Maybe putting some debug prints in interrupt handler and else would help a bit for more understanding.

...

Something leads me to believe that the DMA mask is 32 bits, but

given

...

that the behaviour is similar in both instances, I am unsure.

This isn't a critical issue right now. It can be figured out safely later.

I am now actually 100% positive the DMA mask is 32 bits.

By the way, it's an original X-Fi in this case (I have others to test with). lspci -vvv gives us:

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

Kernel is: Linux version 2.6.27 (nenolod@petrie) (gcc version 4.2.4 (Debian 4.2.4-2 +b1)) #1 SMP Sat Oct 11 11:59:08 CDT 2008

William

At Sun, 12 Oct 2008 21:34:01 +0200, I wrote:

At Sat, 11 Oct 2008 13:04:02 -0500, William Pitcock wrote:

...

Hi,

On Sat, 2008-10-11 at 19:41 +0200, Takashi Iwai wrote:

...

Could you build with XXX_CONST_TIMER defined? This will disable the adaptive timer-resolution handling I added to the driver, which doesn't exist in OSS sbxfi code at all.

No change in behaviour. It survives a little longer, but then the system hardlocks... without me even touching the keyboard even.

This can be a spin deadlock I fixed today. Could you try the latest sound-unstable GIT or snapshot tarball?

FYI, that fix was also broken, and I forgot to push the fix of the fix. My bad.

It should have been fixed now.

You can check the latest git log via http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-unstable-2.6.git;a=sho...

Takashi

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?

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?

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?

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

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

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

At Thu, 16 Oct 2008 18:41:08 +0400, The Source wrote:

Takashi Iwai пишет:

...

At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:

...

Takashi Iwai пишет:

...

At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:

...

...

> And, which X-Fi model do you have? > Please show the lspci -nv output, too. > > > > I've got the X-Fi Elite Pro. That's The one with the external In/Out box.

Speaking of which, the headphone jack on it does not output a signal yet, the signal only goes to line out.

There's some relais on the card that seem to switch these, they click multiple times with the windows driver and not all all with yours, I think that's the reason :)

Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.

The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.

Takashi

Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.

Already fixed.

Takashi

In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)

Hmm, it seems broken for older kernels right now. The easy workaround is to pass --with-cards=sbxfi to configure.

Anyway, I'll fix it now.

thanks,

Takashi

Takashi Iwai пишет:

At Thu, 16 Oct 2008 18:41:08 +0400, The Source wrote:

...

Takashi Iwai пишет:

...

At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:

...

Takashi Iwai пишет:

...

At Thu, 16 Oct 2008 17:36:04 +0400, The Source wrote:

...

>> And, which X-Fi model do you have? >> Please show the lspci -nv output, too. >> >> >> >> >> > I've got the X-Fi Elite Pro. > That's The one with the external In/Out box. > > Speaking of which, the headphone jack on it does not output a signal > yet, the signal only goes to line out. > > There's some relais on the card that seem to switch these, they click > multiple times with the windows driver and not all all with yours, I > think that's the reason :) > > > > Original OSS driver doesn't output to external block also, so it wouldn't be easy to make this support I think.

The values for port->conv[0] and [1] values in sbxfi_playback_open() might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL and DAI_CH_I2SAR, as default. You can try other values, such as, DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on.

Takashi

Latest snapshot has a bug: make[3]: *** No rule to make target `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop.

Already fixed.

Takashi

In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)

Hmm, it seems broken for older kernels right now. The easy workaround is to pass --with-cards=sbxfi to configure.

Anyway, I'll fix it now.

thanks,

Takashi

--Hey, man, this is cool! Plays just fine (volume ok, speed ok, no --glitches) with 96000, 48000, 44100, 22050, 16/24 bit, Stereo and --Mono!! --I didn't change anything in the source code, so I don't use system --timer. Yes!!

However oss (alsa-emulated) is unstable. I'll test more.

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

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

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

alsa-driver-unstable-snapshot.tar.bz2 2864 KB 10/22/2008 04:21:00 PM

Fails to compile

13:42:51 [~/Desktop/alsa-driver-unstable] blub@freax $ ./configure --with-cards=sbxfi,hda-intel --with-debug=detect && make [...] In file included from /home/blub/Desktop/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2: /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: In function 'sbxfi_reprogram_timer': /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: 'SBXFI_TIMER_FRE' undeclared (first use in this function) /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: (Each undeclared identifier is reported only once /home/blub/Desktop/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:356: error: for each function it appears in.) make[4]: *** [/home/blub/Desktop/alsa-driver-unstable/pci/sbxfi/sbxfi.o] Error 1 make[3]: *** [/home/blub/Desktop/alsa-driver-unstable/pci/sbxfi] Error 2 make[2]: *** [/home/blub/Desktop/alsa-driver-unstable/pci] Error 2 make[1]: *** [_module_/home/blub/Desktop/alsa-driver-unstable] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.27' make: *** [compile] Error 2 13:43:33 [~/Desktop/alsa-driver-unstable]

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

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

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

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

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

Takashi Iwai wrote:

Fixed and uploaded now. It might take some time until the changes are sync'ed.

Thanks, downloaded, patched fine. Attached dmesg_modprobe.txt shows output before playing anything.

No sound now using the oss workaround "echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss" Mplayer starts but doesn't increment shows 0% 0seconds etc etc, it can be interrupted ctrl-c, the PC remains functional, just no sound. dmesg_after.txt is the tail end of dmesg after interrupting mplayer, I trimmed it as the first couple seven lines repeat for about 330K in the original log :) Instant reboot when trying mplayer without the oss workaround.

aplay -Dplug:dmix:0 wn.wav still works. Trying mplayer after aplay freezes the machine with no output onto the console.

Thanks again, Jason

SBXFI: IRQ = 0x500 SBXFI: read(0) 0x1b0010 = 0x0 SBXFI: POINTER = 0x3e0 SBXFI: SET TIMER TICKS = 16 SBXFI: write(0) 0x1c6004 = 0xc010 SBXFI: write(0) 0x1c6010 = 0x500 SBXFI: read(0) 0x1c6010 = 0x500 SBXFI: IRQ = 0x500 SBXFI: read(0) 0x1b0010 = 0x0 SBXFI: POINTER = 0x3e0 SBXFI: SET TIMER TICKS = 16 SBXFI: write(0) 0x1c6004 = 0xc010 SBXFI: write(0) 0x1c6010 = 0x500 SBXFI: read(0) 0x1c6010 = 0x500 SBXFI: IRQ = 0x500 SBXFI: read(0) 0x1b0010 = 0x0 SBXFI: POINTER = 0x3e0 SBXFI: SET TIMER TICKS = 16 SBXFI: write(0) 0x1c6004 = 0xc010 SBXFI: write(0) 0x1c6010 = 0x500 ALSA /root/alsa-driver-unstable/acore/pcm_native.c:1498: playback drain error (DMA or IRQ trouble?) SBXFI: PLAY TRIGGER STOP SBXFI: read(0) 0x1b0000 = 0x0 SBXFI: write(0) 0x1b0000 = 0x0 SBXFI: read(0) 0x1b0100 = 0x0 SBXFI: write(0) 0x1b0100 = 0x0 SBXFI: PLAY UPDATE TIMER SBXFI: STOP EMU TIMER SBXFI: write(0) 0x1c6004 = 0x0 SBXFI: write(0) 0x1c6014 = 0x0 SBXFI: DAOIMAP CLEAR SBXFI: write(0) 0x1c5000 = 0x0 SBXFI: write(0) 0x1c5004 = 0x0 SBXFI: write(0) 0x1c5008 = 0x0 SBXFI: write(0) 0x1c500c = 0x0 SBXFI: write(0) 0x1c5010 = 0x0 SBXFI: write(0) 0x1c5014 = 0x0 SBXFI: write(0) 0x1c5018 = 0x0 SBXFI: write(0) 0x1c501c = 0x0 SBXFI: write(0) 0x1c5020 = 0x0 SBXFI: write(0) 0x1c5024 = 0x0 SBXFI: write(0) 0x1c5028 = 0x0 SBXFI: write(0) 0x1c502c = 0x0 SBXFI: write(0) 0x1c5030 = 0x0 SBXFI: write(0) 0x1c5034 = 0x0 SBXFI: write(0) 0x1c5038 = 0x0 SBXFI: write(0) 0x1c503c = 0x0 SBXFI: write(0) 0x1c5040 = 0x0 SBXFI: write(0) 0x1c5044 = 0x0 SBXFI: write(0) 0x1c5048 = 0x0 SBXFI: write(0) 0x1c504c = 0x0 SBXFI: write(0) 0x1c5050 = 0x0 SBXFI: write(0) 0x1c5054 = 0x0 SBXFI: write(0) 0x1c5058 = 0x0 SBXFI: write(0) 0x1c505c = 0x0 SBXFI: write(0) 0x1c5060 = 0x0 SBXFI: write(0) 0x1c5064 = 0x0 SBXFI: write(0) 0x1c5068 = 0x0 SBXFI: write(0) 0x1c506c = 0x0 SBXFI: write(0) 0x1c5070 = 0x0

SBXFI: write(0) 0x1c5074 = 0x0 SBXFI: write(0) 0x1c5078 = 0x0 SBXFI: write(0) 0x1c507c = 0x0 SBXFI: write(0) 0x1c5080 = 0x0 SBXFI: write(0) 0x1c5084 = 0x0 SBXFI: write(0) 0x1c5088 = 0x0 SBXFI: write(0) 0x1c508c = 0x0 SBXFI: write(0) 0x1c5090 = 0x0 SBXFI: write(0) 0x1c5094 = 0x0 SBXFI: write(0) 0x1c5098 = 0x0 SBXFI: write(0) 0x1c509c = 0x0 SBXFI: write(0) 0x1c50a0 = 0x0 SBXFI: write(0) 0x1c50a4 = 0x0 SBXFI: write(0) 0x1c50a8 = 0x0 SBXFI: write(0) 0x1c50ac = 0x0 SBXFI: write(0) 0x1c50b0 = 0x0 SBXFI: write(0) 0x1c50b4 = 0x0 SBXFI: write(0) 0x1c50b8 = 0x0 SBXFI: write(0) 0x1c50bc = 0x0 SBXFI: write(0) 0x1c50c0 = 0x0 SBXFI: write(0) 0x1c50c4 = 0x0 SBXFI: write(0) 0x1c50c8 = 0x0 SBXFI: write(0) 0x1c50cc = 0x0 SBXFI: write(0) 0x1c50d0 = 0x0 SBXFI: write(0) 0x1c50d4 = 0x0 SBXFI: write(0) 0x1c50d8 = 0x0 SBXFI: write(0) 0x1c50dc = 0x0 SBXFI: write(0) 0x1c50e0 = 0x0 SBXFI: write(0) 0x1c50e4 = 0x0 SBXFI: write(0) 0x1c50e8 = 0x0 SBXFI: write(0) 0x1c50ec = 0x0 SBXFI: write(0) 0x1c50f0 = 0x0 SBXFI: write(0) 0x1c50f4 = 0x0 SBXFI: write(0) 0x1c50f8 = 0x0 SBXFI: write(0) 0x1c50fc = 0x0 SBXFI: write(0) 0x1c5100 = 0x0 SBXFI: write(0) 0x1c5104 = 0x0 SBXFI: write(0) 0x1c5108 = 0x0 SBXFI: write(0) 0x1c510c = 0x0 SBXFI: write(0) 0x1c5110 = 0x0 SBXFI: write(0) 0x1c5114 = 0x0 SBXFI: write(0) 0x1c5118 = 0x0 SBXFI: write(0) 0x1c511c = 0x0 SBXFI: write(0) 0x1c5120 = 0x0 SBXFI: write(0) 0x1c5124 = 0x0 SBXFI: write(0) 0x1c5128 = 0x0 SBXFI: write(0) 0x1c512c = 0x0 SBXFI: write(0) 0x1c5130 = 0x0 SBXFI: write(0) 0x1c5134 = 0x0 SBXFI: write(0) 0x1c5138 = 0x0 SBXFI: write(0) 0x1c513c = 0x0 SBXFI: Release SRC 0 [root@sentry ~]#

SBXFI: read(0) 0x1c6010 = 0x0 SBXFI: INIT HW SBXFI: read(0) 0x1c6070 = 0x104000 SBXFI: write(0) 0x1c6070 = 0x104000 SBXFI: write(0) 0x1c6070 = 0x104002 SBXFI: read(0) 0x1c6070 = 0x4002 SBXFI: read(0) 0x1c6070 = 0x104002 SBXFI: write(0) 0x1c6070 = 0x104aa3 SBXFI: read(0) 0x1c6070 = 0x104aa3 SBXFI: write(0) 0x1c6014 = 0x0 SBXFI: write(0) 0x1b102c = 0x0 SBXFI: read(0) 0x1b102c = 0x0 SBXFI: read(0) 0x1c6060 = 0xc08a0 SBXFI: write(0) 0x1c6060 = 0x1480a001 SBXFI: read(0) 0x1c6060 = 0x1000a001 SBXFI: read(0) 0x1c6060 = 0x1480a001 SBXFI: write(0) 0x1c6024 = 0x13fe SBXFI: write(0) 0x13b404 = 0x13 SBXFI: write(0) 0x13b408 = 0x200c01 SBXFI: DAOIMAP CLEAR SBXFI: write(0) 0x1c5000 = 0x0 SBXFI: write(0) 0x1c5004 = 0x0 SBXFI: write(0) 0x1c5008 = 0x0 SBXFI: write(0) 0x1c500c = 0x0 SBXFI: write(0) 0x1c5010 = 0x0 SBXFI: write(0) 0x1c5014 = 0x0 SBXFI: write(0) 0x1c5018 = 0x0 SBXFI: write(0) 0x1c501c = 0x0 SBXFI: write(0) 0x1c5020 = 0x0 SBXFI: write(0) 0x1c5024 = 0x0 SBXFI: write(0) 0x1c5028 = 0x0 SBXFI: write(0) 0x1c502c = 0x0 SBXFI: write(0) 0x1c5030 = 0x0 SBXFI: write(0) 0x1c5034 = 0x0 SBXFI: write(0) 0x1c5038 = 0x0 SBXFI: write(0) 0x1c503c = 0x0 SBXFI: write(0) 0x1c5040 = 0x0 SBXFI: write(0) 0x1c5044 = 0x0 SBXFI: write(0) 0x1c5048 = 0x0 SBXFI: write(0) 0x1c504c = 0x0 SBXFI: write(0) 0x1c5050 = 0x0 SBXFI: write(0) 0x1c5054 = 0x0 SBXFI: write(0) 0x1c5058 = 0x0 SBXFI: write(0) 0x1c505c = 0x0 SBXFI: write(0) 0x1c5060 = 0x0 SBXFI: write(0) 0x1c5064 = 0x0 SBXFI: write(0) 0x1c5068 = 0x0 SBXFI: write(0) 0x1c506c = 0x0 SBXFI: write(0) 0x1c5070 = 0x0 SBXFI: write(0) 0x1c5074 = 0x0 SBXFI: write(0) 0x1c5078 = 0x0 SBXFI: write(0) 0x1c507c = 0x0 SBXFI: write(0) 0x1c5080 = 0x0 SBXFI: write(0) 0x1c5084 = 0x0 SBXFI: write(0) 0x1c5088 = 0x0 SBXFI: write(0) 0x1c508c = 0x0 SBXFI: write(0) 0x1c5090 = 0x0 SBXFI: write(0) 0x1c5094 = 0x0 SBXFI: write(0) 0x1c5098 = 0x0 SBXFI: write(0) 0x1c509c = 0x0 SBXFI: write(0) 0x1c50a0 = 0x0 SBXFI: write(0) 0x1c50a4 = 0x0 SBXFI: write(0) 0x1c50a8 = 0x0 SBXFI: write(0) 0x1c50ac = 0x0 SBXFI: write(0) 0x1c50b0 = 0x0 SBXFI: write(0) 0x1c50b4 = 0x0 SBXFI: write(0) 0x1c50b8 = 0x0 SBXFI: write(0) 0x1c50bc = 0x0 SBXFI: write(0) 0x1c50c0 = 0x0 SBXFI: write(0) 0x1c50c4 = 0x0 SBXFI: write(0) 0x1c50c8 = 0x0 SBXFI: write(0) 0x1c50cc = 0x0 SBXFI: write(0) 0x1c50d0 = 0x0 SBXFI: write(0) 0x1c50d4 = 0x0 SBXFI: write(0) 0x1c50d8 = 0x0 SBXFI: write(0) 0x1c50dc = 0x0 SBXFI: write(0) 0x1c50e0 = 0x0 SBXFI: write(0) 0x1c50e4 = 0x0 SBXFI: write(0) 0x1c50e8 = 0x0 SBXFI: write(0) 0x1c50ec = 0x0 SBXFI: write(0) 0x1c50f0 = 0x0 SBXFI: write(0) 0x1c50f4 = 0x0 SBXFI: write(0) 0x1c50f8 = 0x0 SBXFI: write(0) 0x1c50fc = 0x0 SBXFI: write(0) 0x1c5100 = 0x0 SBXFI: write(0) 0x1c5104 = 0x0 SBXFI: write(0) 0x1c5108 = 0x0 SBXFI: write(0) 0x1c510c = 0x0 SBXFI: write(0) 0x1c5110 = 0x0 SBXFI: write(0) 0x1c5114 = 0x0 SBXFI: write(0) 0x1c5118 = 0x0 SBXFI: write(0) 0x1c511c = 0x0 SBXFI: write(0) 0x1c5120 = 0x0 SBXFI: write(0) 0x1c5124 = 0x0 SBXFI: write(0) 0x1c5128 = 0x0 SBXFI: write(0) 0x1c512c = 0x0 SBXFI: write(0) 0x1c5130 = 0x0 SBXFI: write(0) 0x1c5134 = 0x0 SBXFI: write(0) 0x1c5138 = 0x0 SBXFI: write(0) 0x1c513c = 0x0 SBXFI: INIT DAC SBXFI: read(0) 0x1c6020 = 0x8c00 SBXFI: write(0) 0x1c6020 = 0x8c02 SBXFI: SETUP I2S SBXFI: read(0) 0x1c5420 = 0x0 SBXFI: write(0) 0x1c5420 = 0x94040406

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

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

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

Takashi Iwai wrote:

At Fri, 24 Oct 2008 08:56:47 +0100, Jason Harvey wrote:

...

Takashi Iwai wrote:

...

Thanks. I guess the problem wa

...

Oct 23 20:45:28 sentry kernel: SBXFI: Allocate SRC 0 Oct 23 20:45:28 sentry kernel: SBXFI: allocated TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Setting TLB buffer page 0x1304a000 Oct 23 20:45:28 sentry kernel: SBXFI: release TLB at 0 for 16 pages Oct 23 20:45:28 sentry kernel: SBXFI: Disabling TLB buffer Oct 23 20:45:28 sentry kernel: SBXFI: PLAYBACK PREPARE: rate=96000, period_size=1024, buffer_size=16384

So the stream is started at the state where the TLB is cleared. The fix patch is below (and I already committed it).

Takashi

Yes that has fixed it. Tested with mplayer (still needs oss proc fix) and aplay. Both sounded fine.

Thanks for quick checking.

So, the mplayer problem still exists - supposedly the same symptom? I'll take a look at OSS emulation code later.

Yes, mplayer without the proc oss fix gives an instant reboots with nothing on the console.

Thank you for your heroic work without any xfi hardware!

Jason

At 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

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

At Sun, 26 Oct 2008 09:32:08 +0300, The Source wrote:

Bjoern Olausson пишет:

...

...

Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix.

Confirmed. The stuttering got better, but is still present.

Xine works flawless.

...

aplay still works but only with dmix.

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

Just using "aplay file.wav"

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

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

...

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

No pulseaudio on my machine. Sry.

...

Machine did not crash at any point!

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

But no crash or freez so far.

...

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

I am using vanilla 2.6.27.3

Thanks for you awesome work!

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

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

Tried the latest driver. All is fine (haven't tested recording however) except pulseaudio (doesn't work) and wine (sound is mega-glitchy, possibly because of strange period and buffer sizes it uses: period=544, buffer=8704).

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

thanks,

Takashi

Takashi Iwai пишет:

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

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?

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.

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)

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

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

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

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

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

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

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

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!

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

At Sat, 25 Oct 2008 21:40:40 +0100, Jason Harvey wrote:

Takashi Iwai wrote:

...

At Sat, 25 Oct 2008 21:42:55 +0200, Thomas Scheunemann wrote:

...

...

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

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

...

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

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

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

Now fixed and updated. Thanks!

Latest unstable (25Oct 19:57) works from command line with mplayer, without the proc oss fix. aplay still works but only with dmix.

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

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

What about base_rate=48000 option?

Machine did not crash at any point!

Heh, finally.

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

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

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

thanks,

Takashi

At 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

At Thu, 23 Oct 2008 16:31:56 +0100, Jason Harvey wrote:

Takashi Iwai wrote:

...

One another thing I'm wondering is whether this happens only with OSS. What happens if you do like the following to disable the sample rate conversion?

# echo mplayer 0 0 direct > /proc/asound/card0/pcm0p/oss

That works! Perfect stereo.

Bah, then this sounds like a bug in OSS emulation code? Hmmm, now need to dig into that old crap...

thanks,

Takashi

At Thu, 23 Oct 2008 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