Re: [Alsa-devel] xine with dmix
On Tue, 20 Jan 2004, Michel Dnzer wrote:
On Tue, 2004-01-20 at 17:06, Michel Dnzer wrote:
On Tue, 2004-01-20 at 16:29, Jaroslav Kysela wrote:
On Tue, 20 Jan 2004, Michel Dnzer wrote:
Could you try the attached patch? If you add a line 'slowptr yes' to your
dmix pcm definition, the snd_pcm_delay() function should be more precise.
It seems to work perfectly, thank you very much!
I have to take that back. :(
I had put the slowptr in the wrong place (in the dmixer slave pcm
block), and xine silently fell back to using /dev/dsp (alsa-oss doesn't
seem to work with it). With the slowptr in the right place, I have now
verified that xine uses ALSA with it enabled, but it doesn't seem to
enhance sound quality much if at all.
Sorry for the false confirmation. Any other ideas?
Yes, I've tested xine with dmix today and I figured after several hours of
looking for totaly another problem, that it was 'snd_pcm_wait()' function
which causes trouble in conjunction with the xine ALSA code algorithm.
The result patch (attached to this mail and available also in CVS) is that
xine works with dmix even without the slowptr option! So there is no
reason to make this option as default.
I'm happy that the next direct plugin related bug is solved.
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs? a
? out.txt
? pcm.c.engine
Index: pcm_direct.c
===
RCS file: /cvsroot/alsa/alsa-lib/src/pcm/pcm_direct.c,v
retrieving revision 1.11
diff -u -r1.11 pcm_direct.c
--- pcm_direct.c9 Jan 2004 18:32:05 - 1.11
+++ pcm_direct.c21 Jan 2004 19:18:06 -
@@ -410,15 +410,23 @@
{
snd_pcm_direct_t *dmix = pcm-private_data;
unsigned short events;
- static snd_timer_read_t rbuf[5];/* can be overwriten by multiple
plugins, we don't need the value */
+ /* rbuf might be overwriten by multiple plugins */
+ /* we don't need the value */
+ static snd_timer_read_t rbuf[5];
assert(pfds nfds == 1 revents);
events = pfds[0].revents;
if (events POLLIN) {
- events |= POLLOUT;
- events = ~POLLIN;
+ int empty = 0;
+ if (pcm-stream == SND_PCM_STREAM_PLAYBACK) {
+ events |= POLLOUT;
+ events = ~POLLIN;
+ empty = snd_pcm_mmap_playback_avail(pcm) pcm-avail_min;
+ } else {
+ empty = snd_pcm_mmap_capture_avail(pcm) pcm-avail_min;
+ }
/* empty the timer read queue */
- while (snd_timer_read(dmix-timer, rbuf, sizeof(rbuf)) ==
sizeof(rbuf)) ;
+ while (empty snd_timer_read(dmix-timer, rbuf, sizeof(rbuf)) ==
sizeof(rbuf)) ;
}
*revents = events;
return 0;
Index: pcm_dmix.c
===
RCS file: /cvsroot/alsa/alsa-lib/src/pcm/pcm_dmix.c,v
retrieving revision 1.47
diff -u -r1.47 pcm_dmix.c
--- pcm_dmix.c 20 Jan 2004 15:29:39 - 1.47
+++ pcm_dmix.c 21 Jan 2004 19:18:07 -
@@ -407,7 +407,6 @@
}
dmix-hw_ptr += diff;
dmix-hw_ptr %= pcm-boundary;
- // printf(sync ptr diff = %li\n, diff);
if (pcm-stop_threshold = pcm-boundary) /* don't care */
return 0;
if ((avail = snd_pcm_mmap_playback_avail(pcm)) = pcm-stop_threshold) {
@@ -545,6 +544,7 @@
if (err 0)
return err;
dmix-state = SND_PCM_STATE_RUNNING;
+ snd_pcm_hwsync(dmix-spcm);
dmix-slave_appl_ptr = dmix-slave_hw_ptr = *dmix-spcm-hw.ptr;
avail = snd_pcm_mmap_playback_hw_avail(pcm);
if (avail 0)
Index: pcm_dshare.c
===
RCS file: /cvsroot/alsa/alsa-lib/src/pcm/pcm_dshare.c,v
retrieving revision 1.13
diff -u -r1.13 pcm_dshare.c
--- pcm_dshare.c20 Jan 2004 15:29:39 - 1.13
+++ pcm_dshare.c21 Jan 2004 19:18:07 -
@@ -292,6 +292,7 @@
if (err 0)
return err;
dshare-state = SND_PCM_STATE_RUNNING;
+ snd_pcm_hwsync(dshare-spcm);
dshare-slave_appl_ptr = dshare-slave_hw_ptr = *dshare-spcm-hw.ptr;
avail = snd_pcm_mmap_playback_hw_avail(pcm);
if (avail 0)
Index: pcm_dsnoop.c
===
RCS file: /cvsroot/alsa/alsa-lib/src/pcm/pcm_dsnoop.c,v
retrieving revision 1.13
diff -u -r1.13 pcm_dsnoop.c
--- pcm_dsnoop.c20 Jan 2004 15:29:39 - 1.13
+++ pcm_dsnoop.c21 Jan 2004 19:18:07 -
@@ -274,6 +274,7 @@
if (err 0)
return err;
dsnoop-state = SND_PCM_STATE_RUNNING;
+ snd_pcm_hwsync(dsnoop-spcm);
dsnoop-slave_appl_ptr =
Re: [Alsa-devel] xine with dmix
On Wed, 2004-01-21 at 20:19, Jaroslav Kysela wrote: [...] I've tested xine with dmix today and I figured after several hours of looking for totaly another problem, that it was 'snd_pcm_wait()' function which causes trouble in conjunction with the xine ALSA code algorithm. The result patch (attached to this mail and available also in CVS) is that xine works with dmix even without the slowptr option! Indeed, great work! Thanks again, you rock. -- Earthling Michel Dnzer | 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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] xine with dmix
Jaroslav Kysela wrote: On Tue, 20 Jan 2004, Michel Dänzer wrote: On Tue, 2004-01-20 at 17:06, Michel Dänzer wrote: On Tue, 2004-01-20 at 16:29, Jaroslav Kysela wrote: On Tue, 20 Jan 2004, Michel Dänzer wrote: Could you try the attached patch? If you add a line 'slowptr yes' to your dmix pcm definition, the snd_pcm_delay() function should be more precise. It seems to work perfectly, thank you very much! I have to take that back. :( I had put the slowptr in the wrong place (in the dmixer slave pcm block), and xine silently fell back to using /dev/dsp (alsa-oss doesn't seem to work with it). With the slowptr in the right place, I have now verified that xine uses ALSA with it enabled, but it doesn't seem to enhance sound quality much if at all. Sorry for the false confirmation. Any other ideas? Yes, I've tested xine with dmix today and I figured after several hours of looking for totaly another problem, that it was 'snd_pcm_wait()' function which causes trouble in conjunction with the xine ALSA code algorithm. The result patch (attached to this mail and available also in CVS) is that xine works with dmix even without the slowptr option! So there is no reason to make this option as default. I'm happy that the next direct plugin related bug is solved. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs Thank you very much for your efforts to help xine work with alsa. So, the problem was a bug in alsa? As you have obviously looked very hard now at the xine code, would you have any recommendations for any changes? Cheers James --- 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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] xine with dmix
Jaroslav Kysela wrote: On Tue, 20 Jan 2004, Michel Dänzer wrote: On Tue, 2004-01-20 at 17:06, Michel Dänzer wrote: On Tue, 2004-01-20 at 16:29, Jaroslav Kysela wrote: On Tue, 20 Jan 2004, Michel Dänzer wrote: Could you try the attached patch? If you add a line 'slowptr yes' to your dmix pcm definition, the snd_pcm_delay() function should be more precise. It seems to work perfectly, thank you very much! I have to take that back. :( I had put the slowptr in the wrong place (in the dmixer slave pcm block), and xine silently fell back to using /dev/dsp (alsa-oss doesn't seem to work with it). With the slowptr in the right place, I have now verified that xine uses ALSA with it enabled, but it doesn't seem to enhance sound quality much if at all. Sorry for the false confirmation. Any other ideas? Yes, I've tested xine with dmix today and I figured after several hours of looking for totaly another problem, that it was 'snd_pcm_wait()' function which causes trouble in conjunction with the xine ALSA code algorithm. The result patch (attached to this mail and available also in CVS) is that xine works with dmix even without the slowptr option! So there is no reason to make this option as default. I'm happy that the next direct plugin related bug is solved. Jaroslav I have tried both your patches, but neither of them fix the problem or jerky output. Sound for a short burst, short pause, sound for a short burst, short pause etc. Cheers James --- 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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] xine with dmix
On Tue, 20 Jan 2004, Michel Dnzer wrote:
I'm basically very happy with http://penguinppc.org/~daenzer/asound.conf
and alsa-oss, kudos to all ALSA developers who made this possible.
The only problem I'm having is that xine doesn't work well. Do you agree
with the analysis in
http://sourceforge.net/mailarchive/message.php?msg_id=6793623 ? Can
snd_pcm_delay() be changed to behave as expected by xine? If so, I can
look into it, but I'd need some pointers.
Could you try the attached patch? If you add a line 'slowptr yes' to your
dmix pcm definition, the snd_pcm_delay() function should be more precise.
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs? a
? out.txt
? pcm.c.engine
Index: pcm_direct.h
===
RCS file: /cvsroot/alsa/alsa-lib/src/pcm/pcm_direct.h,v
retrieving revision 1.6
diff -u -r1.6 pcm_direct.h
--- pcm_direct.h7 Dec 2003 09:30:47 - 1.6
+++ pcm_direct.h20 Jan 2004 15:29:06 -
@@ -99,6 +99,7 @@
pid_t server_pid;
snd_timer_t *timer; /* timer used as poll_fd */
int interleaved;/* we have interleaved buffer */
+ int slowptr;/* use slow but more precise ptr updates */
unsigned int channels; /* client's channels */
unsigned int *bindings;
union {
Index: pcm_dmix.c
===
RCS file: /cvsroot/alsa/alsa-lib/src/pcm/pcm_dmix.c,v
retrieving revision 1.46
diff -u -r1.46 pcm_dmix.c
--- pcm_dmix.c 19 Jan 2004 19:48:27 - 1.46
+++ pcm_dmix.c 20 Jan 2004 15:29:07 -
@@ -394,6 +394,8 @@
default:
break;
}
+ if (dmix-slowptr)
+ snd_pcm_hwsync(dmix-spcm);
old_slave_hw_ptr = dmix-slave_hw_ptr;
slave_hw_ptr = dmix-slave_hw_ptr = *dmix-spcm-hw.ptr;
diff = slave_hw_ptr - old_slave_hw_ptr;
@@ -759,6 +761,8 @@
* \param ipc_key IPC key for semaphore and shared memory
* \param ipc_perm IPC permissions for semaphore and shared memory
* \param params Parameters for slave
+ * \param bindings Channel bindings
+ * \param slowptr Slow but more precise pointer updates
* \param root Configuration root
* \param sconf Slave configuration
* \param stream PCM Direction (stream)
@@ -772,6 +776,7 @@
key_t ipc_key, mode_t ipc_perm,
struct slave_params *params,
snd_config_t *bindings,
+ int slowptr,
snd_config_t *root, snd_config_t *sconf,
snd_pcm_stream_t stream, int mode)
{
@@ -833,6 +838,7 @@
pcm-fast_ops = snd_pcm_dmix_fast_ops;
pcm-private_data = dmix;
dmix-state = SND_PCM_STATE_OPEN;
+ dmix-slowptr = slowptr;
if (first_instance) {
ret = snd_pcm_open_slave(spcm, root, sconf, stream, mode);
@@ -1082,7 +1088,7 @@
snd_config_iterator_t i, next;
snd_config_t *slave = NULL, *bindings = NULL, *sconf;
struct slave_params params;
- int bsize, psize, ipc_key_add_uid = 0;
+ int bsize, psize, ipc_key_add_uid = 0, slowptr = 0;
key_t ipc_key = 0;
mode_t ipc_perm = 0600;
int err;
@@ -1142,6 +1148,22 @@
bindings = n;
continue;
}
+ if (strcmp(id, slowptr) == 0) {
+ char *tmp;
+ err = snd_config_get_ascii(n, tmp);
+ if (err 0) {
+ SNDERR(The field slowptr must be a boolean type);
+ return err;
+ }
+ err = snd_config_get_bool_ascii(tmp);
+ free(tmp);
+ if (err 0) {
+ SNDERR(The field slowptr must be a boolean type);
+ return err;
+ }
+ slowptr = err;
+ continue;
+ }
SNDERR(Unknown field %s, id);
return -EINVAL;
}
@@ -1179,7 +1201,7 @@
params.period_size = psize;
params.buffer_size = bsize;
- err = snd_pcm_dmix_open(pcmp, name, ipc_key, ipc_perm, params, bindings,
root, sconf, stream, mode);
+ err = snd_pcm_dmix_open(pcmp, name, ipc_key, ipc_perm, params, bindings,
slowptr, root, sconf, stream, mode);
if (err 0)
snd_config_delete(sconf);
return err;
Index: pcm_dshare.c
===
RCS file: /cvsroot/alsa/alsa-lib/src/pcm/pcm_dshare.c,v
retrieving revision 1.12
diff -u -r1.12 pcm_dshare.c
--- pcm_dshare.c19 Jan 2004 19:48:28 - 1.12
+++
Re: [Alsa-devel] xine with dmix
On Tue, 2004-01-20 at 16:29, Jaroslav Kysela wrote: On Tue, 20 Jan 2004, Michel Dnzer wrote: I'm basically very happy with http://penguinppc.org/~daenzer/asound.conf and alsa-oss, kudos to all ALSA developers who made this possible. The only problem I'm having is that xine doesn't work well. Do you agree with the analysis in http://sourceforge.net/mailarchive/message.php?msg_id=6793623 ? Can snd_pcm_delay() be changed to behave as expected by xine? If so, I can look into it, but I'd need some pointers. Could you try the attached patch? If you add a line 'slowptr yes' to your dmix pcm definition, the snd_pcm_delay() function should be more precise. It seems to work perfectly, thank you very much! -- Earthling Michel Dnzer | 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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] xine with dmix
On Tue, 20 Jan 2004, Michel Dnzer wrote: On Tue, 2004-01-20 at 16:29, Jaroslav Kysela wrote: On Tue, 20 Jan 2004, Michel Dnzer wrote: I'm basically very happy with http://penguinppc.org/~daenzer/asound.conf and alsa-oss, kudos to all ALSA developers who made this possible. The only problem I'm having is that xine doesn't work well. Do you agree with the analysis in http://sourceforge.net/mailarchive/message.php?msg_id=6793623 ? Can snd_pcm_delay() be changed to behave as expected by xine? If so, I can look into it, but I'd need some pointers. Could you try the attached patch? If you add a line 'slowptr yes' to your dmix pcm definition, the snd_pcm_delay() function should be more precise. It seems to work perfectly, thank you very much! Nice. The code is already in CVS, so it will be in 1.0.2. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] 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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] xine with dmix
At Tue, 20 Jan 2004 17:07:02 +0100 (CET), Jaroslav wrote: On Tue, 20 Jan 2004, Michel Dänzer wrote: On Tue, 2004-01-20 at 16:29, Jaroslav Kysela wrote: On Tue, 20 Jan 2004, Michel Dänzer wrote: I'm basically very happy with http://penguinppc.org/~daenzer/asound.conf and alsa-oss, kudos to all ALSA developers who made this possible. The only problem I'm having is that xine doesn't work well. Do you agree with the analysis in http://sourceforge.net/mailarchive/message.php?msg_id=6793623 ? Can snd_pcm_delay() be changed to behave as expected by xine? If so, I can look into it, but I'd need some pointers. Could you try the attached patch? If you add a line 'slowptr yes' to your dmix pcm definition, the snd_pcm_delay() function should be more precise. It seems to work perfectly, thank you very much! Nice. The code is already in CVS, so it will be in 1.0.2. isn't it better to be turned on as default? i don't think the perfomance impact is so big. Takashi --- 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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
