I have found a reason why dmix does not work well with xine.

I have found a reason why dmix does not work well with xine.

[James Courtier-Dutton]

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

See attached file.
It contains a test program, and a readme.txt with details on how to 
configure the dmix device in order to carry out the test.

Basically, the value of snd_pcm_delay() returned when using the dmix 
device is wrong.

See readme.txt in delay-test-0.0.1.tar.bz2 for details.

Cheers
James

[-- Attachment #2: delay-test-0.0.1.tar.bz2 --]
[-- Type: application/octet-stream, Size: 5719 bytes --]

Re: I have found a reason why dmix does not work well with xine.

[Michel Dänzer]

On Wed, 2004-02-04 at 01:38, James Courtier-Dutton wrote:
> See attached file.
> It contains a test program, and a readme.txt with details on how to 
> configure the dmix device in order to carry out the test.
> 
> Basically, the value of snd_pcm_delay() returned when using the dmix 
> device is wrong.

See the recent thread 'xine with dmix' on this very list; Jaroslav
introduced slowptr for this, but the problem here wasn't that but
another bug in snd_pcm_wait() which he also fixed. xine is working well
here now with an alsa-lib CVS snapshot shortly before the 1.0.2 release.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: I have found a reason why dmix does not work well with xine.

[Jaroslav Kysela]

On Wed, 4 Feb 2004, James Courtier-Dutton wrote:

> See attached file.
> It contains a test program, and a readme.txt with details on how to 
> configure the dmix device in order to carry out the test.
> 
> Basically, the value of snd_pcm_delay() returned when using the dmix 
> device is wrong.
> 
> See readme.txt in delay-test-0.0.1.tar.bz2 for details.

Did you some tests with xine and 1.0.2 libraries? I tried to fix all 
problems related to xine there (including the last reported problem from 
you).

The delay values might be affected by this issue: The dmix plugin can
start in the middle of period of the "master" (hw:x device). In this case,
the pointers of the master pcm are updated at different point - from the
dmix look - than the exclusive device does. You can avoid this problem
using the new "slowptr" option - in this case are pointers synced at each
r/w/status operation, but it adds an extra overhead. Anyway, my tests
shows that xine works well also without this option (and I used USB device
for tests which does also additional buffering in the kernel driver so it
more problematic than standard soundcards).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: I have found a reason why dmix does not work well with xine.

[James Courtier-Dutton]

> 
> 
> Did you some tests with xine and 1.0.2 libraries? I tried to fix all 
> problems related to xine there (including the last reported problem from 
> you).
> 
> The delay values might be affected by this issue: The dmix plugin can
> start in the middle of period of the "master" (hw:x device). In this case,
> the pointers of the master pcm are updated at different point - from the
> dmix look - than the exclusive device does. You can avoid this problem
> using the new "slowptr" option - in this case are pointers synced at each
> r/w/status operation, but it adds an extra overhead. Anyway, my tests
> shows that xine works well also without this option (and I used USB device
> for tests which does also additional buffering in the kernel driver so it
> more problematic than standard soundcards).
> 
> 						Jaroslav
> 

I upgraded to latest alsa-lib cvs. Mixed results. :-(
I have found a new problem.
It seems to be fairly random as to which applications work, and which do 
not.
After running xine in a working state for some time, I find that my 
delay-test program fails now, only outputting every other period to the 
speakers. (command used ./delay-test -c2 -Ddmix -r48000 >t1)
Even unloading all the snd-* modules does not help.

I also see strange errors like: -
bash-2.05b# ./delay-test -c2 -Dplug:dmix -r44100 >t1
delay-test: pcm.c:2353: snd_pcm_areas_copy: Assertion `dst_areas' failed.
Aborted
It plays the first 8 periods, then stops with that error.
I have 8 periods per buffer, as you can see below.
Same happens with: -
./delay-test -c2 -Dplughw -r48000 >t1

So, I think that bug is in the "plug" plugin, and not the dmix plugin.

See below for my dmix entry I have put in /usr/share/alsa/alsa.conf

pcm.dmix {
         @args [ SLAVE FORMAT RATE ]
         @args.SLAVE {
                 type string
                 default "hw:0,0"
         }
         @args.FORMAT {
                 type string
                 default S16_LE
         }
         @args.RATE {
                 type integer
                 default 48000
         }
         type dmix
         slowptr yes
         ipc_key 5678293
         ipc_key_add_uid yes
         slave {
                 pcm $SLAVE
                 format $FORMAT
                 rate $RATE
                 period_time 0
                 period_size 315
                 buffer_size 2520
         }
}


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: I have found a reason why dmix does not work well with xine.

[Jaroslav Kysela]

On Wed, 4 Feb 2004, James Courtier-Dutton wrote:

> > 
> > 
> > Did you some tests with xine and 1.0.2 libraries? I tried to fix all 
> > problems related to xine there (including the last reported problem from 
> > you).
> > 
> > The delay values might be affected by this issue: The dmix plugin can
> > start in the middle of period of the "master" (hw:x device). In this case,
> > the pointers of the master pcm are updated at different point - from the
> > dmix look - than the exclusive device does. You can avoid this problem
> > using the new "slowptr" option - in this case are pointers synced at each
> > r/w/status operation, but it adds an extra overhead. Anyway, my tests
> > shows that xine works well also without this option (and I used USB device
> > for tests which does also additional buffering in the kernel driver so it
> > more problematic than standard soundcards).
> > 
> > 						Jaroslav
> > 
> 
> I upgraded to latest alsa-lib cvs. Mixed results. :-(
> I have found a new problem.
> It seems to be fairly random as to which applications work, and which do 
> not.

I had also mixed debugging ;-(

You had a bug in your code (phase was not preserved during write_loop()  
calls) - it took me some time to find this bug. And I had a serious bug in
recoded rate plugin which was available in CVS for a few hours. It should
be ok now (in CVS).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn