[alsa-devel] sbxfi - What works/doesn't summary

Takashi Iwai wrote:
It'd be helpful if someone can summarize the working and non-working cases. For example,
global info: 0. SBXFI model (product name, PCI ID, PCI SSID, cat /proc/asound/cards entry)
- sbxfi driver version (date & HEADs)
- base_rate value
- system details (x86-64, distro, kernel version, etc)
for each app: A. Application name / version B. working or not-working, problem descriptions C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params) D. period_size and buffer_size (ditto, or in kernel message) E. any special options
Maybe also nice on Wiki...
Hi,
Here's my setup and what's currently working.
0. [SB0550 ]: SBXFi - SB XFi (SB0550) SB XFi (SB0550) at 0x3040 irq 28
1. sbxfi driver version (date & HEADs) 26 Oct 2008 ./HEAD - 8682b8b4ced855b01639d85098ca7de23db87c3d Merge branch 'topic/snd-hrtimer' ./alsa-kernel/HEAD - 8f5d017c10e9da0b1e06f674bfc2c764192d090b Merge branch 'topic/sbxfi'
2. base_rate - 48000
3. x86_64, Fedora 9, 2.6.26.6-79.fc9.x86_64
APPS TESTED
Mplayer - dev-SVN-r27841-4.3.0
WORKING
cat /proc/asound/card0/pcm0p/sub0/hw_params
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
Firefox 3.0.2 flash-plugin-10.0.12.36-release.i386
WORKING
cat /proc/asound/card0/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 16384
Enemy Territory Quake Wars worked but crashed after a couple of minutes. Graphics card is new so can't be sure what happened.
If I set Gnome to use OSS I can get sound from Rhythmbox.
Sorry to tag this on to the end of this message, the problems below are likely of my own causing rather than the sbxfi driver...
I'm investigating why when I select alsa or pulse in Gnome I get an error on clicking the test button. "audiotestsrc wave=sine freq=512 ! audioconvert ! audioresample ! gconfaudiosink: Could not open audio device for playback." Selecting OSS and clicking test I hear the sine wave. But I cannot hear any desktop effect noises or the system bell. Same issue with KDE. I hear the log on tune but nothing else from the desktop itself. Possibly my machine is just too messed up and needs a re-install, it's been upgraded continuously from around FC3 and could do with an overhaul.
Regards, Jason

Jason Harvey пишет:
Takashi Iwai wrote:
It'd be helpful if someone can summarize the working and non-working cases. For example,
global info: 0. SBXFI model (product name, PCI ID, PCI SSID, cat /proc/asound/cards entry)
- sbxfi driver version (date & HEADs)
- base_rate value
- system details (x86-64, distro, kernel version, etc)
for each app: A. Application name / version B. working or not-working, problem descriptions C. ALSA or OSS (you can see it in /proc/asound/card*/pcm0/sub0/hw_params) D. period_size and buffer_size (ditto, or in kernel message) E. any special options
Maybe also nice on Wiki...
Hi,
Here's my setup and what's currently working.
[SB0550 ]: SBXFi - SB XFi (SB0550) SB XFi (SB0550) at 0x3040 irq 28
sbxfi driver version (date & HEADs) 26 Oct 2008 ./HEAD - 8682b8b4ced855b01639d85098ca7de23db87c3d Merge branch
'topic/snd-hrtimer' ./alsa-kernel/HEAD - 8f5d017c10e9da0b1e06f674bfc2c764192d090b Merge branch 'topic/sbxfi'
base_rate - 48000
x86_64, Fedora 9, 2.6.26.6-79.fc9.x86_64
APPS TESTED
Mplayer - dev-SVN-r27841-4.3.0
WORKING cat /proc/asound/card0/pcm0p/sub0/hw_params 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
Firefox 3.0.2 flash-plugin-10.0.12.36-release.i386
WORKING cat /proc/asound/card0/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 16384
Enemy Territory Quake Wars worked but crashed after a couple of minutes. Graphics card is new so can't be sure what happened.
If I set Gnome to use OSS I can get sound from Rhythmbox.
Sorry to tag this on to the end of this message, the problems below are likely of my own causing rather than the sbxfi driver...
I'm investigating why when I select alsa or pulse in Gnome I get an error on clicking the test button. "audiotestsrc wave=sine freq=512 ! audioconvert ! audioresample ! gconfaudiosink: Could not open audio device for playback." Selecting OSS and clicking test I hear the sine wave. But I cannot hear any desktop effect noises or the system bell. Same issue with KDE. I hear the log on tune but nothing else from the desktop itself. Possibly my machine is just too messed up and needs a re-install, it's been upgraded continuously from around FC3 and could do with an overhaul.
Regards, Jason _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
You can't hear desktop sounds because they always use pulseaudio no matter what sound system you select as default. For me pulseaudio plays first sound fine after start, others are corrupt along with sound from all other apps. I'll post hw_params later. Also pulseaudio tends to crash often with this driver so I suppose your problem is the same.

The Source wrote:
You can't hear desktop sounds because they always use pulseaudio no matter what sound system you select as default. For me pulseaudio plays first sound fine after start, others are corrupt along with sound from all other apps. I'll post hw_params later. Also pulseaudio tends to crash often with this driver so I suppose your problem is the same.
Can confirm that once pulse (on FC9 at least) gets involved it sounds terrible.
I worked out that I had removed a package pulseaudio-esound-compat at some point in the past and never realised that it contains the symlinks that gets Gnome to start the pulse server. Once that was fixed the desktop effects started working but only out of my USB headset... and nothing I can find in the gui lets me do anything about it.
mplayer and firefox/flash sound terrible, very tinny and scratchy. This is with the base_rate=48000 option set in modprobe.conf
Thanks, Jason

At Tue, 28 Oct 2008 17:40:40 +0000, Jason Harvey wrote:
The Source wrote:
You can't hear desktop sounds because they always use pulseaudio no matter what sound system you select as default. For me pulseaudio plays first sound fine after start, others are corrupt along with sound from all other apps. I'll post hw_params later. Also pulseaudio tends to crash often with this driver so I suppose your problem is the same.
Can confirm that once pulse (on FC9 at least) gets involved it sounds terrible.
I worked out that I had removed a package pulseaudio-esound-compat at some point in the past and never realised that it contains the symlinks that gets Gnome to start the pulse server. Once that was fixed the desktop effects started working but only out of my USB headset... and nothing I can find in the gui lets me do anything about it.
In many cases, the pulse problem comes from the in accurate DMA position calculation. PA is often too aggressively updating buffers.
mplayer and firefox/flash sound terrible, very tinny and scratchy. This is with the base_rate=48000 option set in modprobe.conf
Do you mean a regression with 48kHz in comparison with 96kHz?
Takashi

Takashi Iwai wrote:
At Tue, 28 Oct 2008 17:40:40 +0000, Jason Harvey wrote:
The Source wrote:
You can't hear desktop sounds because they always use pulseaudio no matter what sound system you select as default. For me pulseaudio plays first sound fine after start, others are corrupt along with sound from all other apps. I'll post hw_params later. Also pulseaudio tends to crash often with this driver so I suppose your problem is the same.
Can confirm that once pulse (on FC9 at least) gets involved it sounds terrible.
I worked out that I had removed a package pulseaudio-esound-compat at some point in the past and never realised that it contains the symlinks that gets Gnome to start the pulse server. Once that was fixed the desktop effects started working but only out of my USB headset... and nothing I can find in the gui lets me do anything about it.
In many cases, the pulse problem comes from the in accurate DMA position calculation. PA is often too aggressively updating buffers.
Thanks, I knew there was a reason I stripped pulse out of this machine when I installed FC9. Is that a bug in pulse or is it something that will improve with the sbxfi driver?
mplayer and firefox/flash sound terrible, very tinny and scratchy. This is with the base_rate=48000 option set in modprobe.conf
Do you mean a regression with 48kHz in comparison with 96kHz?
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
While I was poking about in my alsa configuration I noticed that there is no /etc/alsa/cards/SBXFi.conf I think pulse looks for it, get errors shown after running pulseaudio -vv ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.SBXFi.pcm.surround51.0:CARD=0' Would that make any difference to anything? (Sorry if pulse issues are totally off-topic)
Regards, Jason

At Tue, 28 Oct 2008 19:33:19 +0000, Jason Harvey wrote:
Takashi Iwai wrote:
At Tue, 28 Oct 2008 17:40:40 +0000, Jason Harvey wrote:
The Source wrote:
You can't hear desktop sounds because they always use pulseaudio no matter what sound system you select as default. For me pulseaudio plays first sound fine after start, others are corrupt along with sound from all other apps. I'll post hw_params later. Also pulseaudio tends to crash often with this driver so I suppose your problem is the same.
Can confirm that once pulse (on FC9 at least) gets involved it sounds terrible.
I worked out that I had removed a package pulseaudio-esound-compat at some point in the past and never realised that it contains the symlinks that gets Gnome to start the pulse server. Once that was fixed the desktop effects started working but only out of my USB headset... and nothing I can find in the gui lets me do anything about it.
In many cases, the pulse problem comes from the in accurate DMA position calculation. PA is often too aggressively updating buffers.
Thanks, I knew there was a reason I stripped pulse out of this machine when I installed FC9. Is that a bug in pulse or is it something that will improve with the sbxfi driver?
Basically it's a bug of the driver.
mplayer and firefox/flash sound terrible, very tinny and scratchy. This is with the base_rate=48000 option set in modprobe.conf
Do you mean a regression with 48kHz in comparison with 96kHz?
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
While I was poking about in my alsa configuration I noticed that there is no /etc/alsa/cards/SBXFi.conf I think pulse looks for it, get errors shown after running pulseaudio -vv ALSA lib confmisc.c:1286:(snd_func_refer) Unable to find definition 'cards.SBXFi.pcm.surround51.0:CARD=0' Would that make any difference to anything? (Sorry if pulse issues are totally off-topic)
It just tries to non-existing configuration, and you can ignore it.
Takashi

Takashi Iwai wrote:
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
Yes. I also tried mplayer using -ao=alsa or -ao=oss and the sound is still corrupted, even after killing the pulse daemon.
If I get the chance I will put the card into a 32bit machine tomorrow and see how it sounds there.
Thanks, Jason

Jason Harvey пишет:
Takashi Iwai wrote:
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
Yes. I also tried mplayer using -ao=alsa or -ao=oss and the sound is still corrupted, even after killing the pulse daemon.
If I get the chance I will put the card into a 32bit machine tomorrow and see how it sounds there.
Thanks, Jason
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
The sound once corrupted will remain so until driver is restarted.

Jason Harvey пишет:
Takashi Iwai wrote:
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
Yes. I also tried mplayer using -ao=alsa or -ao=oss and the sound is still corrupted, even after killing the pulse daemon.
If I get the chance I will put the card into a 32bit machine tomorrow and see how it sounds there.
Thanks, Jason
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Ok, looks like with the latest snapshot (28.10.2008 15:19:00) pulseaudio works fine. But wine not. The bad thing is I can't get hw_params somehow. When pulseaudio is started hw_params always say 'closed' even if sound is played at this moment. I'll try to remove pulseaudio and test wine again.

The Source пишет:
Jason Harvey пишет:
Takashi Iwai wrote:
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
Yes. I also tried mplayer using -ao=alsa or -ao=oss and the sound is still corrupted, even after killing the pulse daemon.
If I get the chance I will put the card into a 32bit machine tomorrow and see how it sounds there.
Thanks, Jason
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Ok, looks like with the latest snapshot (28.10.2008 15:19:00) pulseaudio works fine. But wine not. The bad thing is I can't get hw_params somehow. When pulseaudio is started hw_params always say 'closed' even if sound is played at this moment. I'll try to remove pulseaudio and test wine again.
Well, I wasn't lucky. Even without pulseaudio hw_params are 'closed' nomatter what.

The Source пишет:
The Source пишет:
Jason Harvey пишет:
Takashi Iwai wrote:
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
Yes. I also tried mplayer using -ao=alsa or -ao=oss and the sound is still corrupted, even after killing the pulse daemon.
If I get the chance I will put the card into a 32bit machine tomorrow and see how it sounds there.
Thanks, Jason
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Ok, looks like with the latest snapshot (28.10.2008 15:19:00) pulseaudio works fine. But wine not. The bad thing is I can't get hw_params somehow. When pulseaudio is started hw_params always say 'closed' even if sound is played at this moment. I'll try to remove pulseaudio and test wine again.
Well, I wasn't lucky. Even without pulseaudio hw_params are 'closed' nomatter what.
Oh, forgot. My card is:
05:00.0 Multimedia audio controller: Creative Labs SB X-Fi Subsystem: Creative Labs Unknown device 002c 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: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at ec00 [size=32] Region 1: Memory at fea00000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at f8000000 (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 00: 02 11 05 00 07 00 10 02 00 00 01 04 08 40 00 00 10: 01 ec 00 00 04 00 a0 fe 00 00 00 00 04 00 00 f8 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 11 2c 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 04 05

The Source пишет:
The Source пишет:
The Source пишет:
Jason Harvey пишет:
Takashi Iwai wrote:
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
Yes. I also tried mplayer using -ao=alsa or -ao=oss and the sound is still corrupted, even after killing the pulse daemon.
If I get the chance I will put the card into a 32bit machine tomorrow and see how it sounds there.
Thanks, Jason
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Ok, looks like with the latest snapshot (28.10.2008 15:19:00) pulseaudio works fine. But wine not. The bad thing is I can't get hw_params somehow. When pulseaudio is started hw_params always say 'closed' even if sound is played at this moment. I'll try to remove pulseaudio and test wine again.
Well, I wasn't lucky. Even without pulseaudio hw_params are 'closed' nomatter what.
Oh, forgot. My card is:
05:00.0 Multimedia audio controller: Creative Labs SB X-Fi Subsystem: Creative Labs Unknown device 002c 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: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at ec00 [size=32] Region 1: Memory at fea00000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at f8000000 (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 00: 02 11 05 00 07 00 10 02 00 00 01 04 08 40 00 00 10: 01 ec 00 00 04 00 a0 fe 00 00 00 00 04 00 00 f8 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 11 2c 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 04 05
Ok, was able to get hw_params: access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1088 buffer_size: 4352
Why so weird values?

At Wed, 29 Oct 2008 08:15:04 +0300, The Source wrote:
Ok, was able to get hw_params: access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1088 buffer_size: 4352
Why so weird values?
Maybe related with the default sample rate 44.1kHz? Who knows...
Does the patch below have any influence? This restricts the period/buffer size aligned to 1024 bytes. Also, it may fix the PCM pointer calculation somehow.
Takashi
--- diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index e67f768..a2d908e 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -122,6 +122,9 @@ struct sbxfi_port { /* TLB entry */ int tlb_index; unsigned int tlb_pages; + /* buffer pointers */ + unsigned int start_addr; + unsigned int buffer_bytes; /* status */ int state; int need_update; @@ -527,8 +530,8 @@ static void sbxfi_playback_start(struct sbxfi *chip, struct sbxfi_port *port) if (port->tlb_index < 0) return; runtime = port->substream->runtime; - start = port->tlb_index * SBXFI_PAGE_SIZE; - loop = start + frames_to_bytes(runtime, runtime->buffer_size); + start = port->start_addr; + loop = start + port->buffer_bytes;
switch (runtime->rate) { case 48000: @@ -579,8 +582,8 @@ static void sbxfi_capture_start(struct sbxfi *chip, struct sbxfi_port *port) if (port->tlb_index < 0) return; runtime = port->substream->runtime; - start = port->tlb_index * SBXFI_PAGE_SIZE; - loop = start + frames_to_bytes(runtime, runtime->buffer_size); + start = port->start_addr; + loop = start + port->buffer_bytes;
switch (runtime->rate) { case 48000: @@ -1320,9 +1323,9 @@ static int sbxfi_playback_open(struct snd_pcm_substream *substream) set_rate_limit(chip, runtime); snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, - 128); + 1024 /*128*/); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, - 128); + 1024 /*128*/); return 0; }
@@ -1349,9 +1352,9 @@ static int sbxfi_capture_open(struct snd_pcm_substream *substream) set_rate_limit(chip, runtime); snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, - 128); + 1024 /*128*/); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, - 128); + 1024 /*128*/); return 0; }
@@ -1399,6 +1402,9 @@ static int sbxfi_playback_prepare(struct snd_pcm_substream *substream) port->frag_count = runtime->period_size; port->need_update = 0;
+ port->start_addr = port->tlb_index * SBXFI_PAGE_SIZE; + port->buffer_bytes = frames_to_bytes(runtime, runtime->buffer_size); + sbxfi_setup_play_pitch(chip, port); sbxfi_setup_play_mixer(chip, port); sbxfi_setup_play_mapper(chip, port); @@ -1417,6 +1423,9 @@ static int sbxfi_capture_prepare(struct snd_pcm_substream *substream) port->frag_count = runtime->period_size; port->need_update = 0;
+ port->start_addr = port->tlb_index * SBXFI_PAGE_SIZE; + port->buffer_bytes = frames_to_bytes(runtime, runtime->buffer_size); + sbxfi_init_adc(chip, chip->capsrc, chip->micboost);
sbxfi_setup_capture_mapper(chip, port); @@ -1477,10 +1486,12 @@ sbxfi_pcm_pointer(struct snd_pcm_substream *substream) unsigned int pos;
pos = sbxfi_read(chip, SRCCA(port->src[0])) & 0x03ffffff; - pos -= port->tlb_index * SBXFI_PAGE_SIZE; + pos -= port->start_addr; /* The pointer is always 128 bytes ahead */ if (pos >= CA_OFFSET) pos -= CA_OFFSET; + else + pos = pos + port->buffer_bytes - CA_OFFSET; pos = bytes_to_frames(runtime, pos); pos %= runtime->buffer_size; LOG(2, "POINTER = 0x%x\n", pos);

Takashi Iwai пишет:
At Wed, 29 Oct 2008 08:15:04 +0300, The Source wrote:
Ok, was able to get hw_params: access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1088 buffer_size: 4352
Why so weird values?
Maybe related with the default sample rate 44.1kHz? Who knows...
Does the patch below have any influence? This restricts the period/buffer size aligned to 1024 bytes. Also, it may fix the PCM pointer calculation somehow.
Takashi
diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index e67f768..a2d908e 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -122,6 +122,9 @@ struct sbxfi_port { /* TLB entry */ int tlb_index; unsigned int tlb_pages;
- /* buffer pointers */
- unsigned int start_addr;
- unsigned int buffer_bytes; /* status */ int state; int need_update;
@@ -527,8 +530,8 @@ static void sbxfi_playback_start(struct sbxfi *chip, struct sbxfi_port *port) if (port->tlb_index < 0) return; runtime = port->substream->runtime;
- start = port->tlb_index * SBXFI_PAGE_SIZE;
- loop = start + frames_to_bytes(runtime, runtime->buffer_size);
start = port->start_addr;
loop = start + port->buffer_bytes;
switch (runtime->rate) { case 48000:
@@ -579,8 +582,8 @@ static void sbxfi_capture_start(struct sbxfi *chip, struct sbxfi_port *port) if (port->tlb_index < 0) return; runtime = port->substream->runtime;
- start = port->tlb_index * SBXFI_PAGE_SIZE;
- loop = start + frames_to_bytes(runtime, runtime->buffer_size);
start = port->start_addr;
loop = start + port->buffer_bytes;
switch (runtime->rate) { case 48000:
@@ -1320,9 +1323,9 @@ static int sbxfi_playback_open(struct snd_pcm_substream *substream) set_rate_limit(chip, runtime); snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
128);
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,1024 /*128*/);
128);
return 0;1024 /*128*/);
}
@@ -1349,9 +1352,9 @@ static int sbxfi_capture_open(struct snd_pcm_substream *substream) set_rate_limit(chip, runtime); snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
128);
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,1024 /*128*/);
128);
return 0;1024 /*128*/);
}
@@ -1399,6 +1402,9 @@ static int sbxfi_playback_prepare(struct snd_pcm_substream *substream) port->frag_count = runtime->period_size; port->need_update = 0;
- port->start_addr = port->tlb_index * SBXFI_PAGE_SIZE;
- port->buffer_bytes = frames_to_bytes(runtime, runtime->buffer_size);
- sbxfi_setup_play_pitch(chip, port); sbxfi_setup_play_mixer(chip, port); sbxfi_setup_play_mapper(chip, port);
@@ -1417,6 +1423,9 @@ static int sbxfi_capture_prepare(struct snd_pcm_substream *substream) port->frag_count = runtime->period_size; port->need_update = 0;
port->start_addr = port->tlb_index * SBXFI_PAGE_SIZE;
port->buffer_bytes = frames_to_bytes(runtime, runtime->buffer_size);
sbxfi_init_adc(chip, chip->capsrc, chip->micboost);
sbxfi_setup_capture_mapper(chip, port);
@@ -1477,10 +1486,12 @@ sbxfi_pcm_pointer(struct snd_pcm_substream *substream) unsigned int pos;
pos = sbxfi_read(chip, SRCCA(port->src[0])) & 0x03ffffff;
- pos -= port->tlb_index * SBXFI_PAGE_SIZE;
- pos -= port->start_addr; /* The pointer is always 128 bytes ahead */ if (pos >= CA_OFFSET) pos -= CA_OFFSET;
- else
pos = bytes_to_frames(runtime, pos); pos %= runtime->buffer_size; LOG(2, "POINTER = 0x%x\n", pos);pos = pos + port->buffer_bytes - CA_OFFSET;
Patch doesn't help. Though it really makes period and buffer to be aligned to 1024. I have discovered however that sound only gets corrupted if wine tries to use alsa directly. If it uses pulseaudio (it's eSound emulation), sound is fine. Other apps (including MPlayer) with pulseaudio work just fine. dmesg output with debug=2 for the case when wine uses alsa directly is attached.

At Wed, 29 Oct 2008 08:03:58 +0300, The Source wrote:
The Source пишет:
Jason Harvey пишет:
Takashi Iwai wrote:
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
Yes. I also tried mplayer using -ao=alsa or -ao=oss and the sound is still corrupted, even after killing the pulse daemon.
If I get the chance I will put the card into a 32bit machine tomorrow and see how it sounds there.
Thanks, Jason
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Ok, looks like with the latest snapshot (28.10.2008 15:19:00) pulseaudio works fine. But wine not. The bad thing is I can't get hw_params somehow. When pulseaudio is started hw_params always say 'closed' even if sound is played at this moment. I'll try to remove pulseaudio and test wine again.
Well, I wasn't lucky. Even without pulseaudio hw_params are 'closed' nomatter what.
It's ridiculous. Does PA really access the right device (i.e. X-fi)?
Takashi

The Source wrote:
The Source пишет:
Jason Harvey пишет:
Takashi Iwai wrote:
Sorry that was a bit ambiguous, I'd never tried 96kHz. Have just changed base_rate to 96kHz and it performs identically to 48kHz. Pulse mangles the sound in just the same manner at 48kHz or 96kHz.
Ah, so you meant mplayer/flash with PA backend?
Yes. I also tried mplayer using -ao=alsa or -ao=oss and the sound is still corrupted, even after killing the pulse daemon.
If I get the chance I will put the card into a 32bit machine tomorrow and see how it sounds there.
Thanks, Jason
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Ok, looks like with the latest snapshot (28.10.2008 15:19:00) pulseaudio works fine. But wine not. The bad thing is I can't get hw_params somehow. When pulseaudio is started hw_params always say 'closed' even if sound is played at this moment. I'll try to remove pulseaudio and test wine again.
Well, I wasn't lucky. Even without pulseaudio hw_params are 'closed' nomatter what.
With the latest unstable I grabbed this afternoon everything is sounding pretty good right now!
pulseaudio is now working.
[jason@quad alsa-kernel]$ cat HEAD 2f280189c7779e0efbeead8eb03b179d141dd196 Merge commit 'stable/master'
I can get hw_params when there is something playing.
cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 96000 (96000/1) period_size: 2048 buffer_size: 16384
Can't get mplayer to play at the same time as flash in firefox but I don't really know if I've ever managed to do that under pulse...
Thank you again Takashi,
Jason
participants (3)
-
Jason Harvey
-
Takashi Iwai
-
The Source