intel8x0.c

intel8x0.c

[Brian Furey]

Hi all,
  I have an intel810 onboard soundcard.I am using the
alsa driver with a VoIP session.
  The intel8x0.c file has a minimum period byte size
of 32 bytes with the minimum no. of periods being
1.The min and max rate is set to 48k. 

How can I find out what actual(runtime) size period
the alsa driver is dealing with? 

Does it use the minimum size as the period size?

 Brian.




	
	
		
___________________________________________________________
WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards  www.yahoo.co.uk/internetcafes 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: intel8x0.c

[Jaroslav Kysela]

On Tue, 30 Mar 2004, Brian Furey wrote:

> 
> Hi all,
>   I have an intel810 onboard soundcard.I am using the
> alsa driver with a VoIP session.
>   The intel8x0.c file has a minimum period byte size
> of 32 bytes with the minimum no. of periods being
> 1.The min and max rate is set to 48k. 
> 
> How can I find out what actual(runtime) size period
> the alsa driver is dealing with? 

After the snd_pcm_hw_params() call, the given hardware parameter
container will have the chosen period size or 
snd_pcm_hw_params_current() creates the current hw_params
container.

Then use snd_pcm_hw_params_get_period_size() or
snd_pcm_hw_params_get_period_time().

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: intel8x0.c

[Brian Furey]

Right Jaroslav,
   that means i would modify intel8x0.c to include a
call to 
snd_pcm_hw_params_get_period_size() or
snd_pcm_hw_params_get_period_time() in the appropriate
place. Write the values returned say to a text file.
Recompile the ALsa driver and re-insert it into the
kernel.Start my application and check contents of text
file.
Am I right in saying this?
Thanks in advance,
Brian.



 --- Jaroslav Kysela <perex@suse.cz> wrote: > On Tue,
30 Mar 2004, Brian Furey wrote:
> 
> > 
> > Hi all,
> >   I have an intel810 onboard soundcard.I am using
> the
> > alsa driver with a VoIP session.
> >   The intel8x0.c file has a minimum period byte
> size
> > of 32 bytes with the minimum no. of periods being
> > 1.The min and max rate is set to 48k. 
> > 
> > How can I find out what actual(runtime) size
> period
> > the alsa driver is dealing with? 
> 
> After the snd_pcm_hw_params() call, the given
> hardware parameter
> container will have the chosen period size or 
> snd_pcm_hw_params_current() creates the current
> hw_params
> container.
> 
> Then use snd_pcm_hw_params_get_period_size() or
> snd_pcm_hw_params_get_period_time().
> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs 


	
	
		
___________________________________________________________
WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards  www.yahoo.co.uk/internetcafes 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: intel8x0.c

[Jaroslav Kysela]

On Tue, 30 Mar 2004, Brian Furey wrote:

> 
> Right Jaroslav,
>    that means i would modify intel8x0.c to include a
> call to 
> snd_pcm_hw_params_get_period_size() or
> snd_pcm_hw_params_get_period_time() in the appropriate
> place. Write the values returned say to a text file.
> Recompile the ALsa driver and re-insert it into the
> kernel.Start my application and check contents of text
> file.
> Am I right in saying this?

I'm talking about application not the driver.
Why you need to modify driver?

						Jaroslav

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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: intel8x0.c

[James Courtier-Dutton]

Brian Furey wrote:
> Hi all,
>   I have an intel810 onboard soundcard.I am using the
> alsa driver with a VoIP session.
>   The intel8x0.c file has a minimum period byte size
> of 32 bytes with the minimum no. of periods being
> 1.The min and max rate is set to 48k. 
> 
> How can I find out what actual(runtime) size period
> the alsa driver is dealing with? 
> 
> Does it use the minimum size as the period size?
> 
>  Brian.
> 

Brian, I am working on a VoIP setup. I am updating the asterisk alsa 
console driver so that it actually works! The current driver is stuck 
round about alsa api 0.5.x
The period size that the sound card is actually using does not really 
matter, if just effects latency. The bigger the period size, the higher 
the latency.
Just set the period size to the smallest the sound card can do, and then 
just read and write to it.
I found that PLAYBACK and CAPTURE directions can have different period 
sizes, so it is better to open separate handles for playback and capture.
In the config setup, you set the buffer and period sizes, and before you 
set them, you can retrieve the current min/max period and buffer sizes.
For playback, it is best to have a certain minimum buffer being full 
most of the time, due to network jitter, and this buffer can act as the 
jitter buffer. The actual size of this is probably best found out from 
trial and error (I have not finished testing this bit yet).
For capture, just poll for input, and then read whatever is in the 
capture buffer and transmit it. You can experiment with different 
methods of early buffer reads, but again, I have not finished testing 
with that, so I can't give you any definite answers.

Another thing to test with could be sampling and playback at 48k.
Most sound cards work at 48k, and this would reduce the period_time. 
(period_size stays the same, but as one is using a higher rate, the 
period_time decreases, and thus latency.) The problems with that is that 
most VoIP is at 8k, so some resampling is required.

Cheers
James


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: intel8x0.c

[Brian Furey]

Thanks James,
   i'm using the GSM-06.10 codec with my VoIP
application.The frame rate is 160 timestamp units or
20 millisecond frames.4 frames are added to a packet
and transmitted. Packets are transmitted at alternate
intervals of 64 and 96 milliseconds. This is due to
the soundcard driver and the period sizes being read
into the buffer.Can the period size the driver is
capturing from the soundcard and putting into the
sending buffer change during execution of a VoIP
session or is it fixed.Given that I have not changed
it, what is the default period size for the ALSA
driver?
I'm basically trying to find out the reason packets
are transmitted at alternate intervals of 64 and 96
milliseconds....and the runtime period size is the key
 
help appreciated,
brian.
--- James Courtier-Dutton <James@superbug.demon.co.uk>
wrote: > Brian Furey wrote:
> > Hi all,
> >   I have an intel810 onboard soundcard.I am using
> the
> > alsa driver with a VoIP session.
> >   The intel8x0.c file has a minimum period byte
> size
> > of 32 bytes with the minimum no. of periods being
> > 1.The min and max rate is set to 48k. 
> > 
> > How can I find out what actual(runtime) size
> period
> > the alsa driver is dealing with? 
> > 
> > Does it use the minimum size as the period size?
> > 
> >  Brian.
> > 
> 
> Brian, I am working on a VoIP setup. I am updating
> the asterisk alsa 
> console driver so that it actually works! The
> current driver is stuck 
> round about alsa api 0.5.x
> The period size that the sound card is actually
> using does not really 
> matter, if just effects latency. The bigger the
> period size, the higher 
> the latency.
> Just set the period size to the smallest the sound
> card can do, and then 
> just read and write to it.
> I found that PLAYBACK and CAPTURE directions can
> have different period 
> sizes, so it is better to open separate handles for
> playback and capture.
> In the config setup, you set the buffer and period
> sizes, and before you 
> set them, you can retrieve the current min/max
> period and buffer sizes.
> For playback, it is best to have a certain minimum
> buffer being full 
> most of the time, due to network jitter, and this
> buffer can act as the 
> jitter buffer. The actual size of this is probably
> best found out from 
> trial and error (I have not finished testing this
> bit yet).
> For capture, just poll for input, and then read
> whatever is in the 
> capture buffer and transmit it. You can experiment
> with different 
> methods of early buffer reads, but again, I have not
> finished testing 
> with that, so I can't give you any definite answers.
> 
> Another thing to test with could be sampling and
> playback at 48k.
> Most sound cards work at 48k, and this would reduce
> the period_time. 
> (period_size stays the same, but as one is using a
> higher rate, the 
> period_time decreases, and thus latency.) The
> problems with that is that 
> most VoIP is at 8k, so some resampling is required.
> 
> Cheers
> James 


	
	
		
___________________________________________________________
WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards  www.yahoo.co.uk/internetcafes 


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: alsa driver data rates

[Brian Furey]

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

Hi James,
Im asking you becuae looking thru the archives you asked a similar question a long time ago.

 i'm using an open source VoIP application with the
alsa driver. My card is the onboard intel8x0.

   My problem is figuring out the patterns I am
getting with the alsa driver when transmitting
packets.
For instance when I use the GSM codec with a packets
size of 80 msecs and 132 bytes, packets are
transmitted at alternate intervals of 64/96 msecs.
When i use G.711 packets of 240 bytes are transmitted
every 32 msecs with an extra packet every 15 pkts.
With G.711 it is obvious that 256 bytes are added to driver sending buffer every 32 msecs.However this does not match for GSM because it needs only 132 bytes every 64/96 msecs.
Can the driver change the amount of data it gets from the soundcard to suit the codec?
Help appreciated,

Brian.



James Courtier-Dutton <James@superbug.demon.co.uk> wrote:
Brian Furey wrote:
> Hi all,
> I have an intel810 onboard soundcard.I am using the
> alsa driver with a VoIP session.
> The intel8x0.c file has a minimum period byte size
> of 32 bytes with the minimum no. of periods being
> 1.The min and max rate is set to 48k. 
> 
> How can I find out what actual(runtime) size period
> the alsa driver is dealing with? 
> 
> Does it use the minimum size as the period size?
> 
> Brian.
> 

Brian, I am working on a VoIP setup. I am updating the asterisk alsa 
console driver so that it actually works! The current driver is stuck 
round about alsa api 0.5.x
The period size that the sound card is actually using does not really 
matter, if just effects latency. The bigger the period size, the higher 
the latency.
Just set the period size to the smallest the sound card can do, and then 
just read and write to it.
I found that PLAYBACK and CAPTURE directions can have different period 
sizes, so it is better to open separate handles for playback and capture.
In the config setup, you set the buffer and period sizes, and before you 
set them, you can retrieve the current min/max period and buffer sizes.
For playback, it is best to have a certain minimum buffer being full 
most of the time, due to network jitter, and this buffer can act as the 
jitter buffer. The actual size of this is probably best found out from 
trial and error (I have not finished testing this bit yet).
For capture, just poll for input, and then read whatever is in the 
capture buffer and transmit it. You can experiment with different 
methods of early buffer reads, but again, I have not finished testing 
with that, so I can't give you any definite answers.

Another thing to test with could be sampling and playback at 48k.
Most sound cards work at 48k, and this would reduce the period_time. 
(period_size stays the same, but as one is using a higher rate, the 
period_time decreases, and thus latency.) The problems with that is that 
most VoIP is at 8k, so some resampling is required.

Cheers
James


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel
		
---------------------------------
  Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now

[-- Attachment #2: Type: text/html, Size: 4286 bytes --]

Re: alsa driver data rates

[James Courtier-Dutton]

Brian Furey wrote:
> Hi James,
> Im asking you becuae looking thru the archives you asked a similar 
> question a long time ago.
> 
>  i'm using an open source VoIP application with the
> alsa driver. My card is the onboard intel8x0.
>    My problem is figuring out the patterns I am
> getting with the alsa driver when transmitting
> packets.
> For instance when I use the GSM codec with a packets
> size of 80 msecs and 132 bytes, packets are
> transmitted at alternate intervals of 64/96 msecs.
> When i use G.711 packets of 240 bytes are transmitted
> every 32 msecs with an extra packet every 15 pkts.
> With G.711 it is obvious that 256 bytes are added to driver sending 
> buffer every 32 msecs.However this does not match for GSM because it 
> needs only 132 bytes every 64/96 msecs.
> Can the driver change the amount of data it gets from the soundcard to 
> suit the codec?
> Help appreciated,
> 
> Brian.
> 
> 

Can you point me to a url for the source?
I think I will understand you a bit better if I see the source code.

Cheers
James


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: alsa driver data rates

[Clemens Ladisch]

Brian Furey wrote:
>  i'm using an open source VoIP application with the
> alsa driver. My card is the onboard intel8x0.
>
>    My problem is figuring out the patterns I am
> getting with the alsa driver when transmitting
> packets.

This depends more on how the VoIP application does things, not on the
driver/soundcard.

> For instance when I use the GSM codec with a packets
> size of 80 msecs and 132 bytes, packets are
> transmitted at alternate intervals of 64/96 msecs.
> When i use G.711 packets of 240 bytes are transmitted
> every 32 msecs with an extra packet every 15 pkts.
> With G.711 it is obvious that 256 bytes are added to driver
> sending buffer every 32 msecs.However this does not match for GSM
> because it needs only 132 bytes every 64/96 msecs.
> Can the driver change the amount of data it gets from the
> soundcard to suit the codec?

Have a look into /proc/asound/card0/pcm0?/sub0/hw_params to see the
period size.  The period size is constant, but if it is small enough
the application can just wait until enough periods have accumulated
for one packet.


HTH
Clemens




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click