Re: Problem with aloop

Re: Problem with aloop

[Benjamin van den Hout]

Gustavo da Silva Serra wrote:

Well, I discovered that only xinelib has this problem. Xmms and
> alsaplayer, for example, don't have this issue. I am testing VLC and it
> seems to work fine. I am not surprised, since the xine source code that
> deals with alsa is huge and ugly, it must be very hard to mantain that.
>

Thanks for your reply! I did some more testing and I can reproduce it as
well with the 8bit mode, it occurrs less frequently. When I switch back to
16 bit it takes only a few tries with aplay to get the hiccups. So it seems
it is a bit more tricky than I initially thought. Xine can be a strange
beast some times, so that's why I used aplay as well. Anybody have some more
ideas how to tackle this problem or point me in the right direction so I can
solve it myself? It seems I am so close to a working solution...

Kind regards,
Benjamin

Re: Problem with aloop

[Gustavo da Silva Serra]

I had some problems until I could figure it out how to configure alsa 
properly in /etc/asound.conf. Maybe this could be your problem? What is 
your alsa version? I heard that aloop didn't work well until 1.0.15, or 
such (alsa guys: is this true?).

Benjamin van den Hout escreveu:
> Gustavo da Silva Serra wrote:
>
> Well, I discovered that only xinelib has this problem. Xmms and
>   
>> alsaplayer, for example, don't have this issue. I am testing VLC and it
>> seems to work fine. I am not surprised, since the xine source code that
>> deals with alsa is huge and ugly, it must be very hard to mantain that.
>>
>>     
>
> Thanks for your reply! I did some more testing and I can reproduce it as
> well with the 8bit mode, it occurrs less frequently. When I switch back to
> 16 bit it takes only a few tries with aplay to get the hiccups. So it seems
> it is a bit more tricky than I initially thought. Xine can be a strange
> beast some times, so that's why I used aplay as well. Anybody have some more
> ideas how to tackle this problem or point me in the right direction so I can
> solve it myself? It seems I am so close to a working solution...
>
> Kind regards,
> Benjamin
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> __________ NOD32 3095 (20080513) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
>   


-- 
Gustavo da Silva Serra        gustavo.serra@tet.com.br
———————————————————————————
Tools & Technologies - T&T Engenheiros Associados Ltda.
Projetos de SW & HW - Desenvolvendo soluções.
Rua Riachuelo, 1098 Conj. 1204
Centro - Porto Alegre - CEP 90010-272
Fone DDR: (51)3220-3290
Fone/Fax: (51)3220-3220 / 3220-3206
http://www.tet.com.br/                                             tet@tet.com.br

Re: Problem with aloop

[Benjamin van den Hout]

Gustavo da Silva Serra wrote:

I had some problems until I could figure it out how to configure alsa
> properly in /etc/asound.conf. Maybe this could be your problem? What is
> your alsa version? I heard that aloop didn't work well until 1.0.15, or
> such (alsa guys: is this true?).
>

My alsa is 1.0.14 but I'm using the 'HG' version of the alsa-drivers and
alsa-kernel packages so that basically gets me the latest-and-greatest
drivers from the source repository if I understand correctly. I saw some
patches coming by in February and they are already in there so I presume I'm
working with the most current source.

I'm intrigued by the asound.conf, is there any specific configuration you
needed to make the aloop device work properly? I'm using the
distro-configured alsa (ubuntu 7.10) and there is no such file somehwere in
/etc. Even on my debian server (running Etch), I can't find it.

Kind regards,
Benjamin

Re: Problem with aloop

[Gustavo da Silva Serra]

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

I tryied to use the HG versions, but they didn't work well for me. Maybe 
you should give the 1.0.16 a try, just to make sure.
I need an asound.conf since my network application uses a very low 
latency, that is not default. I am attaching my asound.conf.
Another possible source of problems are the artsd and esd daemons, are 
they running?

Hope that helps.

Benjamin van den Hout escreveu:
> Gustavo da Silva Serra wrote:
>
> I had some problems until I could figure it out how to configure alsa
>   
>> properly in /etc/asound.conf. Maybe this could be your problem? What is
>> your alsa version? I heard that aloop didn't work well until 1.0.15, or
>> such (alsa guys: is this true?).
>>
>>     
>
> My alsa is 1.0.14 but I'm using the 'HG' version of the alsa-drivers and
> alsa-kernel packages so that basically gets me the latest-and-greatest
> drivers from the source repository if I understand correctly. I saw some
> patches coming by in February and they are already in there so I presume I'm
> working with the most current source.
>
> I'm intrigued by the asound.conf, is there any specific configuration you
> needed to make the aloop device work properly? I'm using the
> distro-configured alsa (ubuntu 7.10) and there is no such file somehwere in
> /etc. Even on my debian server (running Etch), I can't find it.
>
> Kind regards,
> Benjamin
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> __________ NOD32 3095 (20080513) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
>   


-- 
Gustavo da Silva Serra        gustavo.serra@tet.com.br
———————————————————————————
Tools & Technologies - T&T Engenheiros Associados Ltda.
Projetos de SW & HW - Desenvolvendo soluções.
Rua Riachuelo, 1098 Conj. 1204
Centro - Porto Alegre - CEP 90010-272
Fone DDR: (51)3220-3290
Fone/Fax: (51)3220-3220 / 3220-3206
http://www.tet.com.br/                                             tet@tet.com.br


[-- Attachment #2: asound.conf --]
[-- Type: text/plain, Size: 856 bytes --]

pcm.dmixed {
    type dmix
    ipc_key 372891
    ipc_key_add_uid true
    slave {
        pcm "hw:0,0,0"
        period_time 20000
        buffer_time 80000
    }
    bindings {
        0 0
        1 1
    }
}

pcm.playsoftvol {
    type softvol
    slave.pcm "dmixed"
    control {
        name "Master"
        card 0
        device 0
        subdevice 0
    }
}

pcm.dsnooped {
    type dsnoop
    ipc_key 573194
    ipc_key_add_uid true
    slave {
        pcm "hw:0,1,0"
        period_time 20000
        buffer_time 80000
    }
    bindings {
        0 0
        1 1
    }
}

pcm.fullduplex {
    type asym
    playback.pcm "playsoftvol"
    capture.pcm "dsnooped"
}

pcm.!default {
    type plug
    slave.pcm "fullduplex"
}

pcm.dsp0 {
    type plug
    slave.pcm "fullduplex"
}

ctl.mixer0 {
    type hw
    card 0
    device 0
    subdevice 0
}

[-- 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: Problem with aloop

[Benjamin van den Hout]

Gustavo da Silva Serra wrote:

*Sorry, I accidentally left the subject to the digest title. Reposting to
get the threading right*

I tryied to use the HG versions, but they didn't work well for me. Maybe
> you should give the 1.0.16 a try, just to make sure.
> I need an asound.conf since my network application uses a very low
> latency, that is not default. I am attaching my asound.conf.
> Another possible source of problems are the artsd and esd daemons, are
> they running?
>
> Hi Gustavo,

I just downloaded the 10.0.16 version and the code for aloop-kernel.c looked
quite different from the one in the HG version. I was under the
understanding that the HG version is a current development snapshot that
eventually gets tagged into an official 1.0.1xx version. That's not the case
then?

Anyway, I will try with the 10.0.16 version, I see some stuff about a
#define called SND_CARD_LOOPBACK_START_SYNC, that sounds promising perhaps.
I've also looked at the config file you attached, the stuff about
period_time and buffer_size also looks quite interesting and is perhaps
something I should play with then :)

I'll let you know how things work out! Thanks for your continued help, it is
greatly appreciated...

UPDATE: I built the 10.0.16 version of snd-aloop and it seems to perform a
bit better out of the box! I will experiment a bit more...

Kind regards,
Benjamin

Re: Problem with aloop

[Benjamin van den Hout]

Gustavo da Silva Serra wrote:

>    I am developing an application that captures sound and send it
> through a network, just like a sound server. To test it I am using
> kaffeine with alsa output plugin. After some time playing continuously,
> or if I keep moving the position slider backward and forward, I get
> choppy sound. If I close and reopen the capture stream opened by my
> sound server, the sound is restored to good quality. Sometimes I have to
> reopen many times before I get a good sound. When I use kaffeine oss
> output plugin I don't have this issue. I don't have an audio sound card,
> so I don't know if this is an *aloop* issue.

> Here are some details:
>- RedHat EL 4 kernel 2.6.9.55-ELsmp 64bit
>- Alsa 1.0.16
>- Xinelib 1.1.12

Hi all,

I'm experiencing the same problem as Gustavo. In my case I have a SIP
client calling to another PC and I'm injecting audio with aplay (or
amarok, no difference there) into that SIP call. About 8/10 times
everything goes well, the other two times the audio that comes out at
the other PC sounds really choppy. Both PC's are on the same local
network so that is probably not the problem.

What I found out is that if I patch aloop-kernel.c in the 'static
struct snd_pcm_hardware snd_card_loopback_info' to have ".formats =
 (SNDRV_PCM_FMTBIT_S8 )," this problem goes away. But then I'm stuck
with 8 bit audio. It sounds a bit like the aloop device sometimes
doesn't properly synchronise the 16 bit (or 32bit, tried that as well)
samples on both PCM devices and things get mis-aligned. I'm quite new
to ALSA so please don't laugh too hard if I'm missing something here
:)

Any input is greatly appreciated!

Kind regards,
Benjamin van den Hout

Re: Problem with aloop

[Gustavo da Silva Serra]

Benjamin van den Hout escreveu:
> Gustavo da Silva Serra wrote:
>
>   
>>    I am developing an application that captures sound and send it
>> through a network, just like a sound server. To test it I am using
>> kaffeine with alsa output plugin. After some time playing continuously,
>> or if I keep moving the position slider backward and forward, I get
>> choppy sound. If I close and reopen the capture stream opened by my
>> sound server, the sound is restored to good quality. Sometimes I have to
>> reopen many times before I get a good sound. When I use kaffeine oss
>> output plugin I don't have this issue. I don't have an audio sound card,
>> so I don't know if this is an *aloop* issue.
>>     
>
>   
>> Here are some details:
>> - RedHat EL 4 kernel 2.6.9.55-ELsmp 64bit
>> - Alsa 1.0.16
>> - Xinelib 1.1.12
>>     
>
> Hi all,
>
> I'm experiencing the same problem as Gustavo. In my case I have a SIP
> client calling to another PC and I'm injecting audio with aplay (or
> amarok, no difference there) into that SIP call. About 8/10 times
> everything goes well, the other two times the audio that comes out at
> the other PC sounds really choppy. Both PC's are on the same local
> network so that is probably not the problem.
>
> What I found out is that if I patch aloop-kernel.c in the 'static
> struct snd_pcm_hardware snd_card_loopback_info' to have ".formats =
>  (SNDRV_PCM_FMTBIT_S8 )," this problem goes away. But then I'm stuck
> with 8 bit audio. It sounds a bit like the aloop device sometimes
> doesn't properly synchronise the 16 bit (or 32bit, tried that as well)
> samples on both PCM devices and things get mis-aligned. I'm quite new
> to ALSA so please don't laugh too hard if I'm missing something here
> :)
>
> Any input is greatly appreciated!
>
> Kind regards,
> Benjamin van den Hout
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> __________ NOD32 3088 (20080509) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>   

Well, I discovered that only xinelib has this problem. Xmms and 
alsaplayer, for example, don't have this issue. I am testing VLC and it 
seems to work fine. I am not surprised, since the xine source code that 
deals with alsa is huge and ugly, it must be very hard to mantain that.

Problem with aloop

[Gustavo da Silva Serra]

Hi,

    I am developing an application that captures sound and send it 
through a network, just like a sound server. To test it I am using 
kaffeine with alsa output plugin. After some time playing continuously, 
or if I keep moving the position slider backward and forward, I get 
choppy sound. If I close and reopen the capture stream opened by my 
sound server, the sound is restored to good quality. Sometimes I have to 
reopen many times before I get a good sound. When I use kaffeine oss 
output plugin I don't have this issue. I don't have an audio sound card, 
so I don't know if this is an aloop issue.

Here are some details:
- RedHat EL 4 kernel 2.6.9.55-ELsmp 64bit
- Alsa 1.0.16
- Xinelib 1.1.12

Please, if more details are needed I will be happy to provide them.
Thanks in advance.

Re: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Ahmet İnan]

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

more cleanups.

removed some unneeded stuff.
patch is relative to current hg-tree.

http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-hg-aloop-ainan-patch0.diff

Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>

btw, my "nice" idea turned out to be a bitch, again. its really funny how
worse almoust always is better. :(

ahmet

--
admin der abteilung für angewandte mathematik, tel. 0761-203-5626

[-- Attachment #2: alsa-driver-hg-aloop-ainan-patch0.diff --]
[-- Type: text/plain, Size: 1257 bytes --]

diff -r 4ce2c0f9f2ef drivers/aloop-kernel.c
--- a/drivers/aloop-kernel.c	Wed Feb 20 12:46:42 2008 +0100
+++ b/drivers/aloop-kernel.c	Wed Feb 20 15:05:16 2008 +0100
@@ -86,7 +86,6 @@ typedef struct snd_card_loopback_pcm {
 	unsigned int pcm_bps;		/* bytes per second */
 	unsigned int pcm_hz;		/* HZ */
 	unsigned int pcm_irq_pos;	/* IRQ position */
-	unsigned int pcm_buf_pos;	/* position in buffer */
 	unsigned int pcm_period_pos;	/* period aligned pos in buffer */
 	struct snd_pcm_substream *substream;
 	struct snd_card_loopback_cable *cable;
@@ -165,7 +164,6 @@ static int snd_card_loopback_prepare(str
 	dpcm->pcm_size = frames_to_bytes(runtime, runtime->buffer_size);
 	dpcm->pcm_count = frames_to_bytes(runtime, runtime->period_size);
 	dpcm->pcm_irq_pos = 0;
-	dpcm->pcm_buf_pos = 0;
 	dpcm->pcm_period_pos = 0;
 
 	cable->hw.formats = (1ULL << runtime->format);
@@ -216,8 +214,6 @@ static void snd_card_loopback_timer_func
 	spin_lock_irq(&dpcm->lock);
 
 	dpcm->pcm_irq_pos += dpcm->pcm_bps;
-	dpcm->pcm_buf_pos += dpcm->pcm_bps;
-	dpcm->pcm_buf_pos %= dpcm->pcm_size * dpcm->pcm_hz;
 	if (dpcm->pcm_irq_pos >= dpcm->pcm_count * dpcm->pcm_hz) {
 		dpcm->pcm_irq_pos %= dpcm->pcm_count * dpcm->pcm_hz;
 		dpcm->pcm_period_pos += dpcm->pcm_count;

[-- 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: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Takashi Iwai]

At Wed, 20 Feb 2008 15:19:06 +0100,
Ahmet İnan wrote:
> 
> more cleanups.
> 
> removed some unneeded stuff.
> patch is relative to current hg-tree.
> 
> http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-hg-aloop-ainan-patch0.diff
> 
> Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>

Thanks, applied now to HG tree.


Takashi

Re: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Ahmet İnan]

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

removed my old debugging macros.
renamed variables to make it more clear.

[snd-aloop - even more cleanups]
http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-hg-aloop-ainan-patch1.diff
[Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]

i promised to improve and clean up snd-dummy too, so here it is:
reused the same method to improve timing, renamed the variables,
added snd_pcm_format_set_silence on prepare.

[snd-dummy - improved timing, silence on prepare]
http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-kernel-hg-dummy-ainan-patch0.diff
[Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]

patches are relative to current hg-tree.

ahmet

--
admin der abteilung für angewandte mathematik, tel. 0761-203-5626

[-- Attachment #2: alsa-driver-hg-aloop-ainan-patch1.diff --]
[-- Type: text/plain, Size: 3929 bytes --]

diff -r 04f0b432fb15 drivers/aloop-kernel.c
--- a/drivers/aloop-kernel.c	Wed Feb 20 17:10:53 2008 +0100
+++ b/drivers/aloop-kernel.c	Wed Feb 20 23:50:27 2008 +0100
@@ -29,9 +29,6 @@
 #include <sound/pcm.h>
 #include <sound/initval.h>
 
-/* comment in to trash your kernel logfiles */
-/* #define SND_CARD_LOOPBACK_VERBOSE */
-
 MODULE_AUTHOR("Jaroslav Kysela <perex@perex.cz>");
 MODULE_DESCRIPTION("A loopback soundcard");
 MODULE_LICENSE("GPL");
@@ -81,12 +78,12 @@ typedef struct snd_card_loopback_pcm {
 	snd_card_loopback_t *loopback;
 	spinlock_t lock;
 	struct timer_list timer;
-	unsigned int pcm_size;
-	unsigned int pcm_count;
+	unsigned int pcm_buffer_size;
+	unsigned int pcm_period_size;
 	unsigned int pcm_bps;		/* bytes per second */
 	unsigned int pcm_hz;		/* HZ */
 	unsigned int pcm_irq_pos;	/* IRQ position */
-	unsigned int pcm_period_pos;	/* period aligned pos in buffer */
+	unsigned int pcm_buf_pos;	/* position in buffer */
 	struct snd_pcm_substream *substream;
 	struct snd_card_loopback_cable *cable;
 } snd_card_loopback_pcm_t;
@@ -161,10 +158,10 @@ static int snd_card_loopback_prepare(str
 		return -EINVAL;
 	dpcm->pcm_bps = bps;
 	dpcm->pcm_hz = HZ;
-	dpcm->pcm_size = frames_to_bytes(runtime, runtime->buffer_size);
-	dpcm->pcm_count = frames_to_bytes(runtime, runtime->period_size);
+	dpcm->pcm_buffer_size = frames_to_bytes(runtime, runtime->buffer_size);
+	dpcm->pcm_period_size = frames_to_bytes(runtime, runtime->period_size);
 	dpcm->pcm_irq_pos = 0;
-	dpcm->pcm_period_pos = 0;
+	dpcm->pcm_buf_pos = 0;
 
 	cable->hw.formats = (1ULL << runtime->format);
 	cable->hw.rate_min = runtime->rate;
@@ -189,19 +186,6 @@ static int snd_card_loopback_prepare(str
 		cable->capture_valid = 1;
 	}
 
-#ifdef SND_CARD_LOOPBACK_VERBOSE
-	printk(KERN_INFO "snd-aloop(c%dd%ds%d%c): frq=%d chs=%d fmt=%d buf=%d per=%d pers=%d\n",
-			substream->pcm->card->number,
-			substream->pcm->device,
-			substream->stream,
-			(SNDRV_PCM_STREAM_PLAYBACK == substream->stream ? 'p' : 'c'),
-			runtime->rate,
-			runtime->channels,
-			snd_pcm_format_width(runtime->format),
-			frames_to_bytes(runtime, runtime->buffer_size),
-			frames_to_bytes(runtime, runtime->period_size),
-			runtime->periods);
-#endif
 	return 0;
 }
 
@@ -214,10 +198,10 @@ static void snd_card_loopback_timer_func
 	spin_lock_irq(&dpcm->lock);
 
 	dpcm->pcm_irq_pos += dpcm->pcm_bps;
-	if (dpcm->pcm_irq_pos >= dpcm->pcm_count * dpcm->pcm_hz) {
-		dpcm->pcm_irq_pos %= dpcm->pcm_count * dpcm->pcm_hz;
-		dpcm->pcm_period_pos += dpcm->pcm_count;
-		dpcm->pcm_period_pos %= dpcm->pcm_size;
+	if (dpcm->pcm_irq_pos >= dpcm->pcm_period_size * dpcm->pcm_hz) {
+		dpcm->pcm_irq_pos %= dpcm->pcm_period_size * dpcm->pcm_hz;
+		dpcm->pcm_buf_pos += dpcm->pcm_period_size;
+		dpcm->pcm_buf_pos %= dpcm->pcm_buffer_size;
 		spin_unlock_irq(&dpcm->lock);	
 		snd_pcm_period_elapsed(dpcm->substream);
 	} else {
@@ -229,7 +213,7 @@ static snd_pcm_uframes_t snd_card_loopba
 {
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	snd_card_loopback_pcm_t *dpcm = runtime->private_data;
-	return bytes_to_frames(runtime, dpcm->pcm_period_pos);
+	return bytes_to_frames(runtime, dpcm->pcm_buf_pos);
 }
 
 static struct snd_pcm_hardware snd_card_loopback_info =
@@ -263,9 +247,6 @@ static int snd_card_loopback_hw_params(s
 	snd_card_loopback_pcm_t *dpcm = runtime->private_data;
 	struct snd_dma_buffer *dmab = NULL;
 	if (NULL == dpcm->cable->dma_buffer) {
-#ifdef SND_CARD_LOOPBACK_VERBOSE
-		printk(KERN_INFO "snd-aloop: allocating dma buffer\n");
-#endif
 		dmab = kzalloc(sizeof(*dmab), GFP_KERNEL);
 		if (NULL == dmab)
 			return -ENOMEM;
@@ -302,9 +283,6 @@ static int snd_card_loopback_hw_free(str
 	if (NULL == cable->dma_buffer)
 		return 0;
 
-#ifdef SND_CARD_LOOPBACK_VERBOSE
-	printk(KERN_INFO "snd-aloop: freeing dma buffer\n");
-#endif
 	snd_dma_free_pages(cable->dma_buffer);
 	kfree(cable->dma_buffer);
 	cable->dma_buffer = NULL;

[-- Attachment #3: alsa-kernel-hg-dummy-ainan-patch0.diff --]
[-- Type: text/plain, Size: 1987 bytes --]

diff -r 97f6e4d58851 drivers/dummy.c
--- a/drivers/dummy.c	Wed Feb 20 17:13:44 2008 +0100
+++ b/drivers/dummy.c	Thu Feb 21 00:14:46 2008 +0100
@@ -181,10 +181,10 @@ struct snd_dummy_pcm {
 	struct snd_dummy *dummy;
 	spinlock_t lock;
 	struct timer_list timer;
-	unsigned int pcm_size;
-	unsigned int pcm_count;
+	unsigned int pcm_buffer_size;
+	unsigned int pcm_period_size;
 	unsigned int pcm_bps;		/* bytes per second */
-	unsigned int pcm_jiffie;	/* bytes per one jiffie */
+	unsigned int pcm_hz;		/* HZ */
 	unsigned int pcm_irq_pos;	/* IRQ position */
 	unsigned int pcm_buf_pos;	/* position in buffer */
 	struct snd_pcm_substream *substream;
@@ -238,11 +238,15 @@ static int snd_card_dummy_pcm_prepare(st
 	if (bps <= 0)
 		return -EINVAL;
 	dpcm->pcm_bps = bps;
-	dpcm->pcm_jiffie = bps / HZ;
-	dpcm->pcm_size = snd_pcm_lib_buffer_bytes(substream);
-	dpcm->pcm_count = snd_pcm_lib_period_bytes(substream);
+	dpcm->pcm_hz = HZ;
+	dpcm->pcm_buffer_size = snd_pcm_lib_buffer_bytes(substream);
+	dpcm->pcm_period_size = snd_pcm_lib_period_bytes(substream);
 	dpcm->pcm_irq_pos = 0;
 	dpcm->pcm_buf_pos = 0;
+
+	snd_pcm_format_set_silence(runtime->format, runtime->dma_area,
+			bytes_to_samples(runtime, runtime->dma_bytes));
+
 	return 0;
 }
 
@@ -254,11 +258,11 @@ static void snd_card_dummy_pcm_timer_fun
 	spin_lock_irqsave(&dpcm->lock, flags);
 	dpcm->timer.expires = 1 + jiffies;
 	add_timer(&dpcm->timer);
-	dpcm->pcm_irq_pos += dpcm->pcm_jiffie;
-	dpcm->pcm_buf_pos += dpcm->pcm_jiffie;
-	dpcm->pcm_buf_pos %= dpcm->pcm_size;
-	if (dpcm->pcm_irq_pos >= dpcm->pcm_count) {
-		dpcm->pcm_irq_pos %= dpcm->pcm_count;
+	dpcm->pcm_irq_pos += dpcm->pcm_bps;
+	if (dpcm->pcm_irq_pos >= dpcm->pcm_period_size * dpcm->pcm_hz) {
+		dpcm->pcm_irq_pos %= dpcm->pcm_period_size * dpcm->pcm_hz;
+		dpcm->pcm_buf_pos += dpcm->pcm_period_size;
+		dpcm->pcm_buf_pos %= dpcm->pcm_buffer_size;
 		spin_unlock_irqrestore(&dpcm->lock, flags);
 		snd_pcm_period_elapsed(dpcm->substream);
 	} else

[-- Attachment #4: 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: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Takashi Iwai]

At Thu, 21 Feb 2008 01:06:01 +0100,
Ahmet İnan wrote:
At Thu, 21 Feb 2008 01:06:01 +0100,
Ahmet İnan wrote:
> 
> [snd-aloop - even more cleanups]
> http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-hg-aloop-ainan-patch1.diff
> [Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]
> 
> i promised to improve and clean up snd-dummy too, so here it is:
> reused the same method to improve timing, renamed the variables,
> added snd_pcm_format_set_silence on prepare.
> 
> [snd-dummy - improved timing, silence on prepare]
> http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-kernel-hg-dummy-ainan-patch0.diff
> [Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]
> 
> patches are relative to current hg-tree.

Thanks, applied both to HG tree now.


Takashi

Re: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Ahmet İnan]

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

when the time interval for a period is smaller than kernel HZ, then
snd-aloop and snd-dummy cannot call snd_pcm_period_elapsed as fast enough
annymore. this happens for example with games. but the app still needs to
see, that the buffer actually did go further, which is provided by these
patches.

[snd-aloop - better realtime app support]
http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-hg-aloop-ainan-patch2.diff
[Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]

[snd-dummy - better realtime app support]
http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-kernel-hg-dummy-ainan-patch1.diff
[Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]

patches are relative to current hg-tree.

finally even realtime apps like games work smooth.
only one thing left for perfection :)

ahmet

--
admin der abteilung für angewandte mathematik, tel. 0761-203-5626

[-- Attachment #2: alsa-driver-hg-aloop-ainan-patch2.diff --]
[-- Type: text/plain, Size: 1070 bytes --]

diff -r 89222d702376 drivers/aloop-kernel.c
--- a/drivers/aloop-kernel.c	Thu Feb 21 07:54:16 2008 +0100
+++ b/drivers/aloop-kernel.c	Fri Feb 22 18:16:56 2008 +0100
@@ -198,10 +198,10 @@ static void snd_card_loopback_timer_func
 	spin_lock_irq(&dpcm->lock);
 
 	dpcm->pcm_irq_pos += dpcm->pcm_bps;
+	dpcm->pcm_buf_pos += dpcm->pcm_bps;
+	dpcm->pcm_buf_pos %= dpcm->pcm_buffer_size * dpcm->pcm_hz;
 	if (dpcm->pcm_irq_pos >= dpcm->pcm_period_size * dpcm->pcm_hz) {
 		dpcm->pcm_irq_pos %= dpcm->pcm_period_size * dpcm->pcm_hz;
-		dpcm->pcm_buf_pos += dpcm->pcm_period_size;
-		dpcm->pcm_buf_pos %= dpcm->pcm_buffer_size;
 		spin_unlock_irq(&dpcm->lock);	
 		snd_pcm_period_elapsed(dpcm->substream);
 	} else {
@@ -213,7 +213,7 @@ static snd_pcm_uframes_t snd_card_loopba
 {
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	snd_card_loopback_pcm_t *dpcm = runtime->private_data;
-	return bytes_to_frames(runtime, dpcm->pcm_buf_pos);
+	return bytes_to_frames(runtime, dpcm->pcm_buf_pos / dpcm->pcm_hz);
 }
 
 static struct snd_pcm_hardware snd_card_loopback_info =

[-- Attachment #3: alsa-kernel-hg-dummy-ainan-patch1.diff --]
[-- Type: text/plain, Size: 1089 bytes --]

diff -r 1d499d7e155e drivers/dummy.c
--- a/drivers/dummy.c	Thu Feb 21 12:40:00 2008 +0100
+++ b/drivers/dummy.c	Fri Feb 22 18:25:20 2008 +0100
@@ -259,10 +259,10 @@ static void snd_card_dummy_pcm_timer_fun
 	dpcm->timer.expires = 1 + jiffies;
 	add_timer(&dpcm->timer);
 	dpcm->pcm_irq_pos += dpcm->pcm_bps;
+	dpcm->pcm_buf_pos += dpcm->pcm_bps;
+	dpcm->pcm_buf_pos %= dpcm->pcm_buffer_size * dpcm->pcm_hz;
 	if (dpcm->pcm_irq_pos >= dpcm->pcm_period_size * dpcm->pcm_hz) {
 		dpcm->pcm_irq_pos %= dpcm->pcm_period_size * dpcm->pcm_hz;
-		dpcm->pcm_buf_pos += dpcm->pcm_period_size;
-		dpcm->pcm_buf_pos %= dpcm->pcm_buffer_size;
 		spin_unlock_irqrestore(&dpcm->lock, flags);
 		snd_pcm_period_elapsed(dpcm->substream);
 	} else
@@ -274,7 +274,7 @@ static snd_pcm_uframes_t snd_card_dummy_
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct snd_dummy_pcm *dpcm = runtime->private_data;
 
-	return bytes_to_frames(runtime, dpcm->pcm_buf_pos);
+	return bytes_to_frames(runtime, dpcm->pcm_buf_pos / dpcm->pcm_hz);
 }
 
 static struct snd_pcm_hardware snd_card_dummy_playback =

[-- Attachment #4: 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: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Takashi Iwai]

At Fri, 22 Feb 2008 19:05:28 +0100,
Ahmet İnan wrote:
> 
> when the time interval for a period is smaller than kernel HZ, then
> snd-aloop and snd-dummy cannot call snd_pcm_period_elapsed as fast enough
> annymore. this happens for example with games. but the app still needs to
> see, that the buffer actually did go further, which is provided by these
> patches.

Applied to HG tree now.  Thanks.


Takashi

Re: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Ahmet İnan]

> > see, that the buffer actually did go further, which is provided by these
> > patches.
> Applied to HG tree now.  Thanks.

could it be, that you still forgot to apply this patch, but did the other?

[snd-aloop - better realtime app support]
http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-hg-aloop-ainan-patch2.diff
[Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]

or you havent synced home alsa-driver with main repository yet,
then never mind :)

thanks

ahmet

--
admin der abteilung für angewandte mathematik, tel. 0761-203-5626
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Takashi Iwai]

At Sat, 1 Mar 2008 12:55:06 +0100,
Ahmet İnan wrote:
> 
> > > see, that the buffer actually did go further, which is provided by these
> > > patches.
> > Applied to HG tree now.  Thanks.
> 
> could it be, that you still forgot to apply this patch, but did the other?

It was already applied but a different subject.
Please follow the standard patch style at the next time.


Takashi

Re: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Ahmet İnan]

moved module parameter pcm_substreams range check code around, to prevent catastrophe.
removed bogus module parameter pcm_devs code - aloop creates only one pair of devices.
allowed float_le, too.
removed obsolete code.

[snd-aloop - more cleanups]
http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-hg-aloop-ainan-patch3.diff
[Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]

patch is relative to my previous patch.

will fix bogus wiki entries, about the module parameters, too.

ahmet

--
admin der abteilung für angewandte mathematik, tel. 0761-203-5626
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] improved snd-aloop quality when using certain samplerates and kernel HZ

[Takashi Iwai]

At Sun, 2 Mar 2008 00:35:03 +0100,
Ahmet İnan wrote:
> 
> moved module parameter pcm_substreams range check code around, to prevent catastrophe.
> removed bogus module parameter pcm_devs code - aloop creates only one pair of devices.
> allowed float_le, too.
> removed obsolete code.
> 
> [snd-aloop - more cleanups]
> http://www.mathematik.uni-freiburg.de/IAM/homepages/ainan/alsa-driver-hg-aloop-ainan-patch3.diff
> [Signed-off-by: Ahmet İnan <ainan <at> mathematik.uni-freiburg.de>]
> 
> patch is relative to my previous patch.

Please post the patch instead of URL.

Also, it'd be appreciated if you follow the standard rule for
submitting patches.  We follow the linux kernel rule for alsa-driver
tree, too.  See $LINUX/Documentation/SubmittingPatches.


thanks,

Takashi

Re: Problem with aloop

[Ahmet İnan]

ive just read about aloop problems by chance, so excuse the late answer,
for ive disabled recieving mails from this list. so also cc me when replying :)

> repeating stuttering
try tickless kernel, as it improves the quality of timer interrupts dramatically.
dont forget to enable high resolution timer support, hpet and so on.

> synchronization issue at the beginning
this is still not resolved and its a pain in the ass to get this done right.
ive implemented 4 different ways to solve it and im still not happy with what ive got.

> kernel crash when closing
do you really have to put at this manny places this del_timer?
try to find the right place and resubmit. :)

ahmet

--
admin der abteilung für angewandte mathematik, tel. 0761-203-5626
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Problem with aloop

[Benjamin van den Hout]

Hi Ahmet,

ive just read about aloop problems by chance, so excuse the late answer,
> for ive disabled recieving mails from this list. so also cc me when
> replying :)
>

No problem, I'm delighted somebody is answering my e-mails at all :)

> repeating stuttering
> try tickless kernel, as it improves the quality of timer interrupts
> dramatically.
> dont forget to enable high resolution timer support, hpet and so on.
>

OK, excellent tip. Thanks! High resolution timer support is already enabled
and I've got the kernel configured for "realtime" performance (CONFIG_HZ or
whatever it was called set to 1000 etc.). I'll try to see if the tickless
kernel makes any difference.


> > synchronization issue at the beginning
> this is still not resolved and its a pain in the ass to get this done
> right.
> ive implemented 4 different ways to solve it and im still not happy with
> what ive got.
>

The funny thing is, after I reverted to the 10.0.16 release tarball these
stuttering problems went away. So the fixes that were committed in
february/march under the 'fixes realtime behaviour' label actually made
things much worse..


> > kernel crash when closing
> do you really have to put at this manny places this del_timer?
> try to find the right place and resubmit. :)
>

I already presumed it was a bit much, I'll be the last one to deny that! ;-)

But then again, I'm not too familiar with ALSA kernel stuff anyway and the
existing documentation seems a bit sparse. Also, this patch was made as part
of a time-limited project at my company so I sadly couldn't spend more time
on it after I (crudely) fixed the bug. However, I'd love to refine my patch
(in my own spare time). Can you give me any pointers perhaps? They would be
greatly appreciated.

Thanks for taking the time to reply!

Kind regards,
Benjamin

Re: Problem with aloop

[Ahmet İnan]

> > > synchronization issue at the beginning
> > this is still not resolved and its a pain in the ass to get this done
> The funny thing is, after I reverted to the 10.0.16 release tarball these
> stuttering problems went away. So the fixes that were committed in
> february/march under the 'fixes realtime behaviour' label actually made
> things much worse..
without SND_CARD_LOOPBACK_START_SYNC, its still the same. you should really
get a tickless kernel first. otherwise its just pure luck and frustration.

> > try to find the right place and resubmit. :)
> (in my own spare time). Can you give me any pointers perhaps? They would be
usually snd_card_loopback_playback_trigger gets called with
SNDRV_PCM_TRIGGER_STOP whenever the device is about to be closed.
so the next function would be snd_card_loopback_close. try
snd_card_loopback_timer_stop there and report :D

ahmet

-- 
admin der abteilung für angewandte mathematik, tel. 0761-203-5626
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel