sbxfi - What works/doesn't summary

sbxfi - What works/doesn't summary

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

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

Re: sbxfi - What works/doesn't summary

[The Source]

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

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

Re: sbxfi - What works/doesn't summary

[Jason Harvey]

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

Re: sbxfi - What works/doesn't summary

[Takashi Iwai]

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

Re: sbxfi - What works/doesn't summary

[Jason Harvey]

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

Re: sbxfi - What works/doesn't summary

[Takashi Iwai]

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

Re: sbxfi - What works/doesn't summary

[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

Re: sbxfi - What works/doesn't summary

[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
>
>   
The sound once corrupted will remain so until driver is restarted.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: sbxfi - What works/doesn't summary

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

Re: sbxfi - What works/doesn't summary

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

Re: sbxfi - What works/doesn't summary

[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

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

Re: sbxfi - What works/doesn't summary

[The Source]

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

Re: sbxfi - What works/doesn't summary

[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);
+				   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);

Re: sbxfi - What works/doesn't summary

[The Source]

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

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);
> +				   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);
>
>   
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.

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

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

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

Re: sbxfi - What works/doesn't summary

[Takashi Iwai]

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

Re: sbxfi - What works/doesn't summary

[Jason Harvey]

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




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

Re: sbxfi - What works/doesn't summary

[Takashi Iwai]

At Wed, 29 Oct 2008 15:54:00 +0000,
Jason Harvey wrote:
> 
> 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!

Hmm... I haven't changed sbxfi code since yesterday.
The last change was:
   commit 941ec54e47f635f63621d3852253d9ef9b11132f
   Author: Takashi Iwai <tiwai@suse.de>
   Date:   Tue Oct 28 08:00:24 2008 +0100

      sbxfi - Use 48kHz as default

Though, I'm glad to hear that it's working, of course :)

Or, did you apply my last patch I posted?


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

The flash with PA can work with libflashsupport.
It'd be better to use it with flash-10, though.


thanks,

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

Re: sbxfi - What works/doesn't summary

[Jason Harvey]

Takashi Iwai wrote:
> The last change was:
>    commit 941ec54e47f635f63621d3852253d9ef9b11132f
>    Author: Takashi Iwai <tiwai@suse.de>
>    Date:   Tue Oct 28 08:00:24 2008 +0100
>
>       sbxfi - Use 48kHz as default
>
> Though, I'm glad to hear that it's working, of course :)
>
> Or, did you apply my last patch I posted?
>   
> Hmm... I haven't changed sbxfi code since yesterday.
Ah... a little version confusion here...

This morning I downloaded unstable again and tried the patch.
It wasn't working, garbled sound through pulseaudio as previously mentioned.
I worked out my pulse installation was missing a few packages (Fedora 
folk why aren't all pulse related packages named pulse-* ?)
Not sure what changed but once all the pulse pieces were in place and I 
had locked the default device to the sbxfi it all sounded great.
That was without the patch.

Just applied the patch again and everything still works.

>   
>> 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...
>>     
>
> The flash with PA can work with libflashsupport.
> It'd be better to use it with flash-10, though.
Thank you, I had grabbed flash 10 a couple of days ago as I tried to get 
it all going.
Although it was making nice sounds it turns out it was not using pulse.
Now I have the volume control installed I can see what is going on...
Cured flash by installing libflashsupport.i386
libflashsupport.x86_64 package doesn't really help with adobe's i386 
flash. Doh.

Jason