Subject: Re: [ecasound] alsa device as input
From: Jeremy Hall (firstname.lastname@example.org)
Date: Tue Feb 06 2001 - 08:05:16 EET
yes, but I think the comment was like alsa's oss support seems more
efficient than alsa native mode.
I haven't tried it against libaoss (might defeat the purpose but what the
hey) I guess I'll try that soonish.
In the new year, Kai Vehmanen wrote:
> On Mon, 29 Jan 2001, Jeremy Hall wrote:
> > I have found that in the past, /dev/dsp was more efficient than alsa
> > support. This didn't make sense to me at the time, but I found a bytes to
> > frames error in the alsa source (audioio_alsa3.cpp)
> > I haven't checked to see if it still exists.
> The bytes-frames confusion was created when ALSA people decided to change
> all sample counts into frame counts (during 0.6.x developemnt). This
> doesn't directly affect performance, but can mess up the audio output. For
> instance, for normal cd-quality audio, 1 frame consists of a pair of
> 2-byte (16bit) samples (left+right). So confusing sample and frame
> values causes lots of trouble.
> It's actually quite hard to compare the performance of different sound
> drivers. And especially with consumer cards, where the data stream
> bandwidths are relatively small (cd-audio 176kB/s). You can't really use
> xruns for comparison, as only ALSA reports them. You can suffer from
> occasional xruns with OSS drivers without ever knowing about the
> . http://www.eca.cx ... [ audio software for linux ] /\ .
> . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <email@example.com>.
-- To unsubscribe send message 'unsubscribe' in the body of the message to <firstname.lastname@example.org>.
This archive was generated by hypermail 2b28 : Tue Feb 06 2001 - 08:07:51 EET