AW: general audio card Q

AW: general audio card Q

[Karsten Wiese]

> Besides the RME PST card, are there other sound cards which can do
> interrupt driven data transfer to double-buffers (ie. no DMA) for
> playback?

i'm not exactly shure, what is double-buffers...
the turtle beach pinnacle/fiji has shared memory, that can be accessed
simultanously
from the pc & the sound card.

regards, karsten

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code1

Re: AW: general audio card Q

[daniel sheltraw]

Hello again ALSA list

Since it appears that my question may have been a little confusing
I will clarify below. Thanks for any help you can give me.

> > Besides the RME PST card, are there other sound cards which can do
> > interrupt driven data transfer to double-buffers (ie. no DMA) for
> > playback?
>
>i'm not exactly shure, what is double-buffers... the turtle beach 
>pinnacle/fiji has shared memory, that can be accessed
>simultanously from the pc & the sound card.

Some cards/chipsets (RME PST, ESS solo1) allow one to transfer
data for playback (record is similar) using a memory-mapped double-buffer. 
When buffer 1 has emptied its data to the DAC an
interrupt is issued. An ISR then fills buffer 1 with more
sound data while the buffer 2 continues to send its data to
the DAC for playback. When buffer 2 is emptied it causes an
interrupt and an ISR can fill it again. This goes on and on
until all data is played back.

In this method the transfer of the data from memory to the
memory-mapped buffers is performed by the CPU. This is in
contrast to DMA transfer of data where the busmaster on the
sound card controls transfer of data from memory to card.

So far I only know of the two cards mentioned above but there
must be others that allow data tranfser in this manner. I would
like to know which cards have the capablity to do this whether
or not ALSA supports this method yet in their drivers.

Thanks again,
Love ALSA!
Daniel Sheltraw





_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

Re: AW: general audio card Q

[Paul Davis]

>>i'm not exactly shure, what is double-buffers... the turtle beach 
>>pinnacle/fiji has shared memory, that can be accessed
>>simultanously from the pc & the sound card.
>
>Some cards/chipsets (RME PST, ESS solo1) allow one to transfer
>data for playback (record is similar) using a memory-mapped double-buffer. 
>When buffer 1 has emptied its data to the DAC an
>interrupt is issued. An ISR then fills buffer 1 with more
>sound data while the buffer 2 continues to send its data to
>the DAC for playback. When buffer 2 is emptied it causes an
>interrupt and an ISR can fill it again. This goes on and on
>until all data is played back.

this has nothing to do with DMA or not. what you're describing in ALSA
terms is a configuration with 2 periods per buffer. nothing more
less. just about all ALSA support hardware allows for this
configuration; a few don't allow anything else.

the question as i read it was about cards that cannot do DMA. no
matter how many periods, buffers or whatever, they rely on the host
CPU to move data into memory on their hardware. such cards are rare,
and getting rarer. see rui's recent post for a description of how
cards that do use DMA use it.

>In this method the transfer of the data from memory to the
>memory-mapped buffers is performed by the CPU. This is in
>contrast to DMA transfer of data where the busmaster on the
>sound card controls transfer of data from memory to card.

No, this has nothing to do with "double buffering". "double buffering"
is a description of a particular configuration, not a mechanism. it
can be accomplished in various ways.

>So far I only know of the two cards mentioned above but there
>must be others that allow data tranfser in this manner. I would
>like to know which cards have the capablity to do this whether
>or not ALSA supports this method yet in their drivers.

cards that do not use DMA should generally be considered inferior
because of the extra CPU cycles they force on the host system. 

ALSA neither supports nor not-supports this in the drivers. Its an
implementation detail for the low-level (h/w specific) driver code;
the mid-level code knows nothing about it.

--p


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

Re: AW: general audio card Q

[daniel sheltraw]

Paul

Thanks for your reply and the education. My main reason behind asking
this question is that I am using the RME PST card presently to do
CPU controlled transfer of data to the memory mapped buffers in those
cards. I am interested in using the CPU to do the transfer since
I have heard that DMA or busmastering produces many millisecond latency
in sound data playback. Such latency would be unacceptable in my app.
BTW I am using RTAI to schedule tasks.

I see in the ESS docs that many (maybe all) of their chipsets do
something similar to the RME PST card except that the ESS does
not use mapped-memory buffers. Instead it appears the use a single
FIFO which generates interrupts as the data in the FIFO moves past
the half-full (half empty :-) mark). These fifos are much smaller
than the RME buffers if I recall correctly. The ESS docs refer to
this as "ping-pong" transfer of sound data. I naive have called
both the RME and ESS "ping-pong" methods double-buffering. My error.

So I guess I should say that I am looking for cards that can use
the ping-pong method in addition to the RME and ESS chipsets.

Where does the DMA latency arise?

Thanks again,
Daniel Sheltraw




>From: Paul Davis <pbd@op.net>
>To: "daniel sheltraw" <l5gibson@hotmail.com>
>CC: annabellesgarden@yahoo.de, alsa-devel@alsa-project.org
>Subject: Re: AW: [Alsa-devel] general audio card Q Date: Tue, 30 Jul 2002 
>19:25:50 -0400
>
> >>i'm not exactly shure, what is double-buffers... the turtle beach
> >>pinnacle/fiji has shared memory, that can be accessed
> >>simultanously from the pc & the sound card.
> >
> >Some cards/chipsets (RME PST, ESS solo1) allow one to transfer
> >data for playback (record is similar) using a memory-mapped 
>double-buffer.
> >When buffer 1 has emptied its data to the DAC an
> >interrupt is issued. An ISR then fills buffer 1 with more
> >sound data while the buffer 2 continues to send its data to
> >the DAC for playback. When buffer 2 is emptied it causes an
> >interrupt and an ISR can fill it again. This goes on and on
> >until all data is played back.
>
>this has nothing to do with DMA or not. what you're describing in ALSA
>terms is a configuration with 2 periods per buffer. nothing more
>less. just about all ALSA support hardware allows for this
>configuration; a few don't allow anything else.
>
>the question as i read it was about cards that cannot do DMA. no
>matter how many periods, buffers or whatever, they rely on the host
>CPU to move data into memory on their hardware. such cards are rare,
>and getting rarer. see rui's recent post for a description of how
>cards that do use DMA use it.
>
> >In this method the transfer of the data from memory to the
> >memory-mapped buffers is performed by the CPU. This is in
> >contrast to DMA transfer of data where the busmaster on the
> >sound card controls transfer of data from memory to card.
>
>No, this has nothing to do with "double buffering". "double buffering"
>is a description of a particular configuration, not a mechanism. it
>can be accomplished in various ways.
>
> >So far I only know of the two cards mentioned above but there
> >must be others that allow data tranfser in this manner. I would
> >like to know which cards have the capablity to do this whether
> >or not ALSA supports this method yet in their drivers.
>
>cards that do not use DMA should generally be considered inferior
>because of the extra CPU cycles they force on the host system.
>
>ALSA neither supports nor not-supports this in the drivers. Its an
>implementation detail for the low-level (h/w specific) driver code;
>the mid-level code knows nothing about it.
>
>--p
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: Dice - The leading online job board
>for high-tech professionals. Search and apply for tech jobs today!
>http://seeker.dice.com/seeker.epl?rel_code=31
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/alsa-devel




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

AW: general audio card Q

[Karsten Wiese]

Paul wrote:

> cards that do not use DMA should generally be considered inferior
> because of the extra CPU cycles they force on the host system.

not generally. i.e. the pinnacle/fiji way is to map a piece of memory into
the pc's memory space.
thus an application using alsa-mmap can write (or read) directly into the
cards pcm-memory.
pretty efficiently, don't you think? (except that its ISA-memory)
(it can do so with 2 or 3 periods per buffer).
I don't see any drawback here caused by the lack of DMA.

regards, Karsten

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code1

Re: AW: general audio card Q

[Paul Davis]

>Paul wrote:
>
>> cards that do not use DMA should generally be considered inferior
>> because of the extra CPU cycles they force on the host system.
>
>not generally. i.e. the pinnacle/fiji way is to map a piece of memory into
>the pc's memory space.
>thus an application using alsa-mmap can write (or read) directly into the
>cards pcm-memory.
>pretty efficiently, don't you think? (except that its ISA-memory)
>(it can do so with 2 or 3 periods per buffer).
>I don't see any drawback here caused by the lack of DMA.

yes, but this isn't what I mean by "a card that doesn't use
DMA". cards that don't use DMA require the host CPU to issue an
instruction per-small-piece-of-data to move it from host memory to the
interface memory. what you're describing is still instruction-free
movement of data between the two. the fact that the mapping is
interface->host rather than host->interface (as on the rme9652,
sblive, ice1712 and others) doesn't change that all that much.

--p


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

Re: AW: general audio card Q

[Paul Davis]

>Thanks for your reply and the education. My main reason behind asking
>this question is that I am using the RME PST card presently to do
>CPU controlled transfer of data to the memory mapped buffers in those
>cards. I am interested in using the CPU to do the transfer since
>I have heard that DMA or busmastering produces many millisecond latency
>in sound data playback. Such latency would be unacceptable in my app.
>BTW I am using RTAI to schedule tasks.

well, you've heard wrong. mostly.

all that is needed to reduce latencies to the absolute minimum (the
PCI bus limit of 64 bytes) is an accurate way to read the hardware
pointer on the interface at any time. some interfaces have this, some
don't. without it, you are limited to relying on interrupt-driven
transfer, which is where the latency comes in, regardless of whether
DMA is used or not.

the only additional latency comes from the transfer size used by the
interface. some interfaces don't go down to the PCI bus limit, but
only ever use DMA to move somewhat larger chunks. even then, the size
is pretty small - typically smaller than the typical lower limit for
the interrupt interval: 1-2msec (64 frames at 48kHz).

>I see in the ESS docs that many (maybe all) of their chipsets do
>something similar to the RME PST card except that the ESS does
>not use mapped-memory buffers. Instead it appears the use a single
>FIFO which generates interrupts as the data in the FIFO moves past
>the half-full (half empty :-) mark). These fifos are much smaller
>than the RME buffers if I recall correctly. The ESS docs refer to
>this as "ping-pong" transfer of sound data. I naive have called
>both the RME and ESS "ping-pong" methods double-buffering. My error.

no, this *is* double buffering, at least as the
windows/macos/ASIO/EASI world refers to it. 2 interrupts (periods) per
buffer.

>So I guess I should say that I am looking for cards that can use
>the ping-pong method in addition to the RME and ESS chipsets.

almost every card supported by ALSA can do this. the question is: how
big is the "FIFO"?

>Where does the DMA latency arise?

i think you're really confused about all this. there are two
orthogonal questions:

	   1) how does data move from/to the host memory to/from the
              interface?
           2) when does data move from/to the host memory to/from the
              interface? 

the first question has 3 possible answers (perhaps other, but none
that i know of):

  * the interface maps a section of host memory, and accesses it
      via the PCI bus (DMA)
  * the host maps a section of interface memory, and accesses it
      via the PCI bus
  * the host uses specific instructions to move data to/from the interface
      (for example, via some FIFO on the interface that is accessed
       via IO-space registers)

the second has two possible answers that i know of:

  * data transfer occurs on receipt of an interrupt from the interface
  * data transfer occurs at various times based on the amount
     of space/data available in the buffer, indicated by the
     location of the interface's hardware pointer

the hardware pointer is used even for interrupts, since its possible
that an interrupt was missed, and assuming that you know the
space/data available is a bad idea.

I hope this makes it clearer.

--p




-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31