Tips on debugging ALSA driver snd_es18xx

Tips on debugging ALSA driver snd_es18xx

[Paulo Marcel Coelho Aragao]

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

Hi,

I recently switched from OSS to ALSA and I'm baffled by this: aplay produces 
sound when playing wav files, but gxine and xmms produce no sound when playing 
streaming audio. I traced them and observed that they accessed sound in the 
same way, calling open() and ioctl() on /dev/snd/pcmC0D0p and 
/dev/snd/controlC0.

I started threads at alsa-user and xine-users which didn't reach a conclusion 
so far. I also tried linux-audio-user and debian-user but nobody replied. Of 
course, long hours googling, too. With the tools and knowledge (lack of) I 
have, I feel I can get no further. I thought of filing a bug (don't know 
against which package, actually) but then, what the heck, I should try doing 
something about it first. Perhaps I spent too much time working with 
commercial software and I still see myself expecting my problem to be solved 
by somebody else. Time to change that and get into the Linux way.

With this frame of mind, I come here asking for guidance: could anybody share 
with me some tips about debugging my ALSA driver, snd_es18xx ? A confession of 
ignorance: I've never hacked a Linux kernel, never compiled Linux software 
from source, for that matter, but I'm willing to learn what it takes to get to 
the bottom of this problem.

I've attached the output of http://alsa.opensrc.org/aadebug.txt, to describe 
my environment.

Thanks
Paulo

[-- Attachment #2: aadebug.log --]
[-- Type: text/plain, Size: 2106 bytes --]

ALSA Audio Debug v0.1.0 - Wed Dec 14 09:50:33 BRDT 2005
http://alsa.opensrc.org/index.php?page=aadebug
http://www.gnu.org/licenses/gpl.txt

Kernel ----------------------------------------------------
Linux cortazar 2.6.14-2-686 #2 Fri Dec 9 10:11:34 UTC 2005 i686 GNU/Linux

Loaded Modules --------------------------------------------
snd_es18xx             31496  1 
snd_pcm_oss            55264  0 
snd_mixer_oss          19808  1 snd_pcm_oss
snd_pcm                92392  2 snd_es18xx,snd_pcm_oss
snd_page_alloc         10952  1 snd_pcm
snd_opl3_lib           10848  1 snd_es18xx
snd_timer              24708  2 snd_pcm,snd_opl3_lib
snd_hwdep               9184  1 snd_opl3_lib
snd_mpu401_uart         7328  1 snd_es18xx
snd_rawmidi            24896  1 snd_mpu401_uart
snd_seq_device          8748  2 snd_opl3_lib,snd_rawmidi
snd                    55940  12 snd_es18xx,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_opl3_lib,snd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device

Modprobe Conf ---------------------------------------------
alias char-major-14-* soundcore

Proc Asound -----------------------------------------------
Advanced Linux Sound Architecture Driver Version 1.0.10rc1 (Mon Sep 12 08:13:09 2005 UTC).
0 [ES1879         ]: ES1879 - ESS AudioDrive ES1879
                     ESS AudioDrive ES1879 at 0x220, irq 5, dma1 1, dma2 5
  8: [0- 0]: raw midi
  4: [0- 0]: hardware dependent
 16: [0- 0]: digital audio playback
 24: [0- 0]: digital audio capture
  0: [0- 0]: ctl
 33:       : timer
00-00: OPL3 FM
00-00: ES1879 : ESS AudioDrive ES1879 : playback 2 : capture 1

Dev Snd ---------------------------------------------------
controlC0  hwC0D0  midiC0D0  pcmC0D0c  pcmC0D0p  timer

CPU -------------------------------------------------------
model name	: Celeron (Mendocino)
cpu MHz		: 298.688

RAM -------------------------------------------------------
MemTotal:       159172 kB
SwapTotal:      313256 kB

Hardware --------------------------------------------------
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 03)

Re: Tips on debugging ALSA driver snd_es18xx

[Clemens Ladisch]

Paulo Marcel Coelho Aragao wrote:
> I recently switched from OSS to ALSA and I'm baffled by this: aplay produces
> sound when playing wav files, but gxine and xmms produce no sound when
> playing streaming audio.

What are the contents of /proc/asound/card0/pcm0p/sub0/hw_params and sw_params
in either case?


Regards,
Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Paulo Marcel Coelho Aragao]

Clemens Ladisch wrote on Dec, 15:
> > I recently switched from OSS to ALSA and I'm baffled by this: aplay 
> > produces
> > sound when playing wav files, but gxine and xmms produce no sound when
> > playing streaming audio.
> 
> What are the contents of /proc/asound/card0/pcm0p/sub0/hw_params and sw_params
> in either case?

Hey, this is interesting. Thanks for answering. I'm not clear about what this 
means but it feels pointing to a promising direction.

This was curious: the wav files I tried with aplay ended too quickly, so I 
looked for longer ones. My surprise: no sound from the longer ones. It gave me 
the impression to be related to the sound source being coded for 16 or 8-bits, 
if I'm not speaking just plain nonsense. I ran aplay -v which seemed to 
display the same info you asked.

Thanks, Clemens, for taking the time with my predicament
Paulo

PS: Would have at hand a reference to some document that describes 
/proc/asound ?

[SOUND]

aplay -v /usr/share/sounds/KDE_Beep_Honk.wav
--------------------------------------------
Playing WAVE '/usr/share/sounds/KDE_Beep_Honk.wav' : Unsigned 8 bit, Rate 
11127 Hz, Mono
Plug PCM: Rate conversion PCM (11130, sformat=U8)
Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : U8
subformat    : STD
channels     : 1
rate         : 11127
exact rate   : 11127 (11127/1)
msbits       : 8
buffer_size  : 5564
period_size  : 1391
period_time  : 124977
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 1391
xfer_align   : 1391
start_threshold  : 5564
stop_threshold   : 5564
silence_threshold: 0
silence_size : 0
boundary     : 1458569216
Slave: Hardware PCM card 0 'ESS AudioDrive ES1879' device 0 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : U8
subformat    : STD
channels     : 1
rate         : 11130
exact rate   : 11130.4 (768000/69)
msbits       : 8
buffer_size  : 5567
period_size  : 1391
period_time  : 124977
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 1391
xfer_align   : 1391
start_threshold  : 5564
stop_threshold   : 5567
silence_threshold: 0
silence_size : 0
boundary     : 1459355648

[NO SOUND]

gxine rtsp://128.59.222.11:554/broadcast/wkcr.rm?cloakport=80,554,7070
----------------------------------------------------------------------
/proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (793800/18)
period_size: 2048
buffer_size: 16384
tick_time: 1000

/proc/asound/card0/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 2048
xfer_align: 1
start_threshold: 2048
stop_threshold: 16384
silence_threshold: 0
silence_size: 0
boundary: 1073741824

xmms http://64.236.34.67:80/stream/1018
---------------------------------------
/proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (793800/18)
period_size: 2205
buffer_size: 16384
tick_time: 1000

/proc/asound/card0/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 2205
xfer_align: 2205
start_threshold: 14179
stop_threshold: 16384
silence_threshold: 0
silence_size: 0
boundary: 1073741824

aplay -v /usr/share/sounds/alsa/Front_Right.wav
-----------------------------------------------
Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little 
Endian, Rate 48000 Hz, Mono
Plug PCM: Hardware PCM card 0 'ESS AudioDrive ES1879' device 0 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 48000
exact rate   : 48000 (768000/16)
msbits       : 16
buffer_size  : 24000
period_size  : 6000
period_time  : 125000
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 0
avail_min    : 6000
xfer_align   : 6000
start_threshold  : 24000
stop_threshold   : 24000
silence_threshold: 0
silence_size : 0
boundary     : 1572864000


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Takashi Iwai]

At Thu, 15 Dec 2005 09:12:13 -0200,
Paulo Marcel Coelho Aragao wrote:
> 
> Clemens Ladisch wrote on Dec, 15:
> > > I recently switched from OSS to ALSA and I'm baffled by this: aplay 
> > > produces
> > > sound when playing wav files, but gxine and xmms produce no sound when
> > > playing streaming audio.
> > 
> > What are the contents of /proc/asound/card0/pcm0p/sub0/hw_params and sw_params
> > in either case?
> 
> Hey, this is interesting. Thanks for answering. I'm not clear about what this 
> means but it feels pointing to a promising direction.
> 
> This was curious: the wav files I tried with aplay ended too quickly, so I 
> looked for longer ones. My surprise: no sound from the longer ones. It gave me 
> the impression to be related to the sound source being coded for 16 or 8-bits, 
> if I'm not speaking just plain nonsense. I ran aplay -v which seemed to 
> display the same info you asked.

Might it be depending on the sample rate?
Try speaker-test, for example, with different sample rates.

> 
> Thanks, Clemens, for taking the time with my predicament
> Paulo
> 
> PS: Would have at hand a reference to some document that describes 
> /proc/asound ?

alsa-kernel/Documentation/Procfile.txt (in kernel tree
linux/Documentation/sounds/alsa/Procfile.txt).


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Paulo Marcel Coelho Aragao]

Takashi Iwai wrote on Dec, 15:

[...]

> > > > I recently switched from OSS to ALSA and I'm baffled by this: aplay 
> > > > produces
> > > > sound when playing wav files, but gxine and xmms produce no sound when
> > > > playing streaming audio.

> > > What are the contents of /proc/asound/card0/pcm0p/sub0/hw_params and sw_params
> > > in either case?

[...]

> > This was curious: the wav files I tried with aplay ended too quickly, so I 
> > looked for longer ones. My surprise: no sound from the longer ones. It gave me 
> > the impression to be related to the sound source being coded for 16 or 
> > 8-bits, if I'm not speaking just plain nonsense.

[...]

> Might it be depending on the sample rate?
> Try speaker-test, for example, with different sample rates.

Tried all rates from the aplay/gxine/xmms runs, and also lower and higher 
rates but no sound at all, not even with 11127Hz, the rate of the aplay run 
that produced sound.

I did notice this line in all speaker-test runs:

Stream parameters are 11127Hz, S16_LE, 1 channels

of course with a differen rate at each run. S16_LE is the format for all 
aplay/gxine/xmms runs that didn't produce sound. I don't know precisely what 
`format' is, but the aplay run that produced sound had a different value: U8.

[...]

> > PS: Would have at hand a reference to some document that describes 
> > /proc/asound ?

> alsa-kernel/Documentation/Procfile.txt (in kernel tree
> linux/Documentation/sounds/alsa/Procfile.txt).

Thanks for this, and more so, thanks for taking your time with such 
speed-lightning reply.
Paulo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Paulo Marcel Coelho Aragao]

Takashi Iwai wrote on Dec, 15:

[...]

> > > > I recently switched from OSS to ALSA and I'm baffled by this: aplay 
> > > > produces
> > > > sound when playing wav files, but gxine and xmms produce no sound when
> > > > playing streaming audio.

> > > What are the contents of /proc/asound/card0/pcm0p/sub0/hw_params and sw_params
> > > in either case?

[...]

> > This was curious: the wav files I tried with aplay ended too quickly, so I 
> > looked for longer ones. My surprise: no sound from the longer ones. It gave me 
> > the impression to be related to the sound source being coded for 16 or 
> > 8-bits, if I'm not speaking just plain nonsense.

[...]

> Might it be depending on the sample rate?
> Try speaker-test, for example, with different sample rates.

Tried all rates from the aplay/gxine/xmms runs, and also lower and higher 
rates but no sound at all, not even with 11127Hz, the rate of the aplay run 
that produced sound.

I did notice this line in all speaker-test runs:

Stream parameters are 11127Hz, S16_LE, 1 channels

of course with a differen rate at each run. S16_LE is the format for all 
aplay/gxine/xmms runs that didn't produce sound. I don't know precisely what 
`format' is, but the aplay run that produced sound had a different value: U8.

[...]

> > PS: Would have at hand a reference to some document that describes 
> > /proc/asound ?

> alsa-kernel/Documentation/Procfile.txt (in kernel tree
> linux/Documentation/sounds/alsa/Procfile.txt).

It just occurred to me now: should I record this problem in ALSA BTS for 
future reference ?

Thanks for this, and more so, thanks for taking your time with such 
speed-lightning reply.
Paulo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Clemens Ladisch]

Paulo Marcel Coelho Aragao wrote:
> This was curious: the wav files I tried with aplay ended too quickly, so I
> looked for longer ones. My surprise: no sound from the longer ones. It gave
> me the impression to be related to the sound source being coded for 16 or
> 8-bits, if I'm not speaking just plain nonsense.

Please add this to your ~/.asoundrc:

pcm.u8 {
	type plug
	slave.pcm {
		type linear
		slave {
			pcm "hw:0"
			format U8
		}
	}
}

and try to play some 16-bit file to the ALSA device named "u8" instead of the
default one.  If this works, there is a bug in the driver in relation with
16-bit data.


Regards,
Clemens


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Paulo Marcel Coelho Aragao]

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

Clemens Ladisch wrote on Dec, 15:
> > This was curious: the wav files I tried with aplay ended too quickly, so I
> > looked for longer ones. My surprise: no sound from the longer ones. It gave
> > me the impression to be related to the sound source being coded for 16 or
> > 8-bits, if I'm not speaking just plain nonsense.
> 
> Please add this to your ~/.asoundrc:
> 
> pcm.u8 {
> 	type plug
> 	slave.pcm {
> 		type linear
> 		slave {
> 			pcm "hw:0"
> 			format U8
> 		}
> 	}
> }

May I ask you what this snippet does ?

> and try to play some 16-bit file to the ALSA device named "u8" instead of the
> default one.  If this works, there is a bug in the driver in relation with
> 16-bit data.

Fantastic, Clemens ! You hit the bull's eye. Now the scenario is:

1) aplay -Du8 produces sound from 8 or 16-bit data (the same I used before) on 
   both speakers

2) xmms and gxine produce sound only on the left speaker. I've attached a file 
   with the few config parameters which are explicitly set for gxine (the rest 
   is commented out, therefore, default). xmms saves every single parameter, 
   so I'm just sending the ALSA stanza.  My eye didn't catch anything that 
   might be related to usage of left/right speakers. Just in case, I'm also 
   attaching my mixer settings.

3) speaker-test -Du8 produces what I suppose is pink noise on both speakers, 
   but I noticed that its output included only "0 - Front Left"

I guess we're almost there. I thought I'd be doing the hard work, but you've 
been doing everything. I'm really happy and thankful for having posted the 
problem here. Now I've got to capitalize on this and learn more.

Would you have any suggestions regarding (2) ?

If this is indeed a bug in the driver, should I file a bug in ALSA BTS ?

Thanks immensely for your providencial help
Paulo

[-- Attachment #2: amixer_contents --]
[-- Type: text/plain, Size: 3461 bytes --]

numid=2,iface=MIXER,name='Master Playback Switch'
  ; type=BOOLEAN,access=rw---,values=2
  : values=on,on
numid=1,iface=MIXER,name='Master Playback Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=63,step=0
  : values=55,56
numid=28,iface=MIXER,name='Hardware Master Volume Split'
  ; type=BOOLEAN,access=rw---,values=1
  : values=off
numid=27,iface=MIXER,name='Hardware Master Playback Switch'
  ; type=BOOLEAN,access=r----,values=2
  : values=on,on
numid=26,iface=MIXER,name='Hardware Master Playback Volume'
  ; type=INTEGER,access=r----,values=2,min=0,max=63,step=0
  : values=55,56
numid=24,iface=MIXER,name='3D Control - Level'
  ; type=INTEGER,access=rw---,values=1,min=0,max=63,step=0
  : values=63
numid=25,iface=MIXER,name='3D Control - Switch'
  ; type=BOOLEAN,access=rw---,values=1
  : values=on
numid=14,iface=MIXER,name='PCM Playback Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=15,iface=MIXER,name='PCM Playback Volume',index=1
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=16,iface=MIXER,name='PCM Capture Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=5,iface=MIXER,name='FM Playback Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=19,iface=MIXER,name='FM Capture Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=0,0
numid=3,iface=MIXER,name='Line Playback Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=18,iface=MIXER,name='Line Capture Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=0,0
numid=4,iface=MIXER,name='CD Playback Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=21,iface=MIXER,name='CD Capture Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=14,14
numid=23,iface=MIXER,name='Mic Boost (+26dB)'
  ; type=BOOLEAN,access=rw---,values=1
  : values=off
numid=7,iface=MIXER,name='Mic Playback Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=17,iface=MIXER,name='Mic Capture Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=0,0
numid=9,iface=MIXER,name='PC Speaker Playback Volume'
  ; type=INTEGER,access=rw---,values=1,min=0,max=7,step=0
  : values=7
numid=8,iface=MIXER,name='Aux Playback Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=22,iface=MIXER,name='Aux Capture Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=0,0
numid=6,iface=MIXER,name='Mono Playback Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=15,15
numid=20,iface=MIXER,name='Mono Capture Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=0,0
numid=13,iface=MIXER,name='Capture Source'
  ; type=ENUMERATED,access=rw---,values=1,items=8
  ; Item #0 'Mic'
  ; Item #1 'Mic Master'
  ; Item #2 'CD'
  ; Item #3 'AOUT'
  ; Item #4 'Mic1'
  ; Item #5 'Mix'
  ; Item #6 'Line'
  ; Item #7 'Master'
  : values=7
numid=12,iface=MIXER,name='Capture Switch'
  ; type=BOOLEAN,access=rw---,values=1
  : values=on
numid=11,iface=MIXER,name='Capture Volume'
  ; type=INTEGER,access=rw---,values=2,min=0,max=15,step=0
  : values=10,10
numid=10,iface=MIXER,name='Record Monitor'
  ; type=BOOLEAN,access=rw---,values=1
  : values=off


[-- Attachment #3: gxine.cfg --]
[-- Type: text/plain, Size: 294 bytes --]

gui.experience_level:Master of the known universe
gui.post_plugins.audio_visualisation:None
audio.driver:alsa
audio.device.alsa_default_device:u8
audio.device.alsa_front_device:u8
video.driver:opengl
video.output.opengl_renderer:2D_Tex
engine.performance.memcpy_method:mmx
misc.wizards_shown:6

[-- Attachment #4: xmms.cfg --]
[-- Type: text/plain, Size: 157 bytes --]

[ALSA]
buffer_time=500
period_time=50
thread_buffer_time=3000
pcm_device=u8
mixer_card=0
mixer_device=PCM
soft_volume=FALSE
volume_left=100
volume_right=100

Re: Tips on debugging ALSA driver snd_es18xx

[Takashi Iwai]

At Thu, 15 Dec 2005 14:52:03 -0200,
Paulo Marcel Coelho Aragao wrote:
> 
> Clemens Ladisch wrote on Dec, 15:
> > > This was curious: the wav files I tried with aplay ended too quickly, so I
> > > looked for longer ones. My surprise: no sound from the longer ones. It gave
> > > me the impression to be related to the sound source being coded for 16 or
> > > 8-bits, if I'm not speaking just plain nonsense.
> > 
> > Please add this to your ~/.asoundrc:
> > 
> > pcm.u8 {
> > 	type plug
> > 	slave.pcm {
> > 		type linear
> > 		slave {
> > 			pcm "hw:0"
> > 			format U8
> > 		}
> > 	}
> > }
> 
> May I ask you what this snippet does ?

This configuration forces to use 8bit-unsigned format.  If any other
formats are given, it's converted to u8 automatically.

> 
> > and try to play some 16-bit file to the ALSA device named "u8" instead of the
> > default one.  If this works, there is a bug in the driver in relation with
> > 16-bit data.
> 
> Fantastic, Clemens ! You hit the bull's eye. Now the scenario is:
> 
> 1) aplay -Du8 produces sound from 8 or 16-bit data (the same I used before) on 
>    both speakers

I guess you're using a mono wav file?

> 2) xmms and gxine produce sound only on the left speaker. I've attached a file 
>    with the few config parameters which are explicitly set for gxine (the rest 
>    is commented out, therefore, default). xmms saves every single parameter, 
>    so I'm just sending the ALSA stanza.  My eye didn't catch anything that 
>    might be related to usage of left/right speakers. Just in case, I'm also 
>    attaching my mixer settings.

This implies that u8-stereo doesn't work.

> 3) speaker-test -Du8 produces what I suppose is pink noise on both speakers, 
>    but I noticed that its output included only "0 - Front Left"

It means u8-mono works as expected, at least.


> I guess we're almost there. I thought I'd be doing the hard work, but you've 
> been doing everything. I'm really happy and thankful for having posted the 
> problem here. Now I've got to capitalize on this and learn more.
> 
> Would you have any suggestions regarding (2) ?
> 
> If this is indeed a bug in the driver, should I file a bug in ALSA BTS ?

As you like.  We can continue the debug session on alsa-devel ML, too.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Paulo Marcel Coelho Aragao]

Takashi Iwai wrote on Dec, 15:

[...]

> > > Please add this to your ~/.asoundrc:
> > > 
> > > pcm.u8 {
> > > 	type plug
> > > 	slave.pcm {
> > > 		type linear
> > > 		slave {
> > > 			pcm "hw:0"
> > > 			format U8
> > > 		}
> > > 	}
> > > }

[...]

> This configuration forces to use 8bit-unsigned format.  If any other
> formats are given, it's converted to u8 automatically.

This means that the driver processes the data in 8bit-unsigned chunks ?

> > > and try to play some 16-bit file to the ALSA device named "u8" instead 
> > > of the
> > > default one.  If this works, there is a bug in the driver in relation with
> > > 16-bit data.

> > Fantastic, Clemens ! You hit the bull's eye. Now the scenario is:
> > 
> > 1) aplay -Du8 produces sound from 8 or 16-bit data (the same I used before) on 
> >    both speakers

> I guess you're using a mono wav file?

I don't know how to inspect it. Could you give me a hint ? It's 
/usr/share/sounds/alsa/Front_Right.wav from Debian package alsa-utils.

> > 2) xmms and gxine produce sound only on the left speaker. I've attached a file 
> >    with the few config parameters which are explicitly set for gxine (the rest 
> >    is commented out, therefore, default). xmms saves every single parameter, 
> >    so I'm just sending the ALSA stanza.  My eye didn't catch anything that 
> >    might be related to usage of left/right speakers. Just in case, I'm also 
> >    attaching my mixer settings.

> This implies that u8-stereo doesn't work.

Should it work ?

> > 3) speaker-test -Du8 produces what I suppose is pink noise on both speakers, 
> >    but I noticed that its output included only "0 - Front Left"

> It means u8-mono works as expected, at least.

[...]

> > If this is indeed a bug in the driver, should I file a bug in ALSA BTS ?

> As you like.  We can continue the debug session on alsa-devel ML, too.

As long as we get to the bottom of this and squash this bug, the context 
doesn't matter to me. So, grasshopper Paulo asks Masters Takashi and Clemens: 
what's the next step ? I guess the goal is making 16-bit work, right ?

Thanks a lot, Takashi, for spending your time on this
Paulo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Paulo Marcel Coelho Aragao]

Paulo Marcel Coelho Aragao wrote on Dec, 15:

[...]

> > > If this is indeed a bug in the driver, should I file a bug in ALSA BTS ?
> 
> > As you like.  We can continue the debug session on alsa-devel ML, too.
> 
> As long as we get to the bottom of this and squash this bug, the context 
> doesn't matter to me. So, grasshopper Paulo asks Masters Takashi and 
> Clemens: what's the next step ? I guess the goal is making 16-bit work, 
> right ?

Is there anything I can do to help debug this further and squash the bug ?

Paulo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Tips on debugging ALSA driver snd_es18xx

[Takashi Iwai]

At Fri, 16 Dec 2005 12:28:45 -0200,
Paulo Marcel Coelho Aragao wrote:
> 
> Paulo Marcel Coelho Aragao wrote on Dec, 15:
> 
> [...]
> 
> > > > If this is indeed a bug in the driver, should I file a bug in ALSA BTS ?
> > 
> > > As you like.  We can continue the debug session on alsa-devel ML, too.
> > 
> > As long as we get to the bottom of this and squash this bug, the context 
> > doesn't matter to me. So, grasshopper Paulo asks Masters Takashi and 
> > Clemens: what's the next step ? I guess the goal is making 16-bit work, 
> > right ?
> 
> Is there anything I can do to help debug this further and squash the bug ?

We need to trace the flow of the code.  The first thing is to know
which DAC is used in your case.  es18xx driver has two DACs for
playback, depending on the model.  Since it provides no proc interface
for register dumps, you'll need to add printk's in some places to get
register setting, etc.

The points to check are first snd_es18xx_playback_open().  Check which
condition is satisfied in that callback via printk.  Then follow
snd_es18xx_playback_hw_params() and snd_es18xx_playback_prepare()
callbacks.  The prepare callback is the most important set-up part.
The trigger callback is then used for starting/stopping the stream.

The datasheet for ES18xx is available on alsa's ftp site.  Compare the
values the driver sets with the datasheet.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click