Re: AW: [Alsa-devel] general audio card Q
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 [EMAIL PROTECTED] To: daniel sheltraw [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
AW: [Alsa-devel] general audio card Q
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: AW: [Alsa-devel] general audio card Q
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: AW: [Alsa-devel] general audio card Q
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: AW: [Alsa-devel] general audio card Q
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: AW: [Alsa-devel] general audio card Q
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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
