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

Attaching dmesg output.