Fw: writing audiowerk driver (philips saa7146a), some questions

Fw: writing audiowerk driver (philips saa7146a), some questions

[Martijn Sipkema]

below is a message i sent earlier, but with the wrong email address:

----

writing audiowerk driver (philips saa7146a), some questions


 hi,

 i have finally been able to get the information i need to be able
 to write a driver for the emagic audiowerk8 audio interface.
 now since i am not an experienced kernel programmer and have
 not even done audio programming (apart from midi), i have
 some questions.

 - should i use the normal double buffered aproach or does having
 more than 2 buffers have advantages?

 - what is normally called the latency of an audio interface for output?
 is this the total size of the buffers or (in the case of double buffered
io)
 only one buffer? i'm thinking it is the total buffer size and this would
 make using more than 2 buffers have a better latency/interrupt response
 time ratio, right?

 - should setting the buffer size and number be done on modules loading
 or should it be possible to change it after that? the saa7146 doesn't need
 contiguous memory since it has a mmu.

 - where can i find documentation on writing alsa drivers? what would be
 the best driver source to use for documentation?

 - does alsa allow varipitch? i think the new rme cards are supposed to
 have this feature and the audiowerk8 has it, i.e. it can change its
sampling
 rate from about 37700 to 58200 hz while running in 1hz increments.
 this allows for sync to video/tape/midi or whatever. or it allows for the
 sample rate to be adjusted when receiving audio using rtp.

 - the audiowerk8 uses three dma channels: one for input and two for output.
 should i just wake a process that is blocking on a read() from the input
dma
 interrupt or should i wait until all three dma channels are ready and then
 unblock all read()/write() processes? should unblocking the processes be
 done
 from bottom half?

 --martijn





_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a), some questions

[tomasz motylewski]

On Fri, 31 May 2002, Martijn Sipkema wrote:

>  - does alsa allow varipitch? i think the new rme cards are supposed to
>  have this feature and the audiowerk8 has it, i.e. it can change its
> sampling
>  rate from about 37700 to 58200 hz while running in 1hz increments.
>  this allows for sync to video/tape/midi or whatever. or it allows for the
>  sample rate to be adjusted when receiving audio using rtp.

Can the frequency be changed without stopping (no loss of sound)? If so it is
an interesting feature, but I am not sure if supported by ALSA.

Best regards,
--
Tomasz Motylewski


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a), some questions

[Martijn Sipkema]

> >  - does alsa allow varipitch? i think the new rme cards are supposed to
> >  have this feature and the audiowerk8 has it, i.e. it can change its
> > sampling
> >  rate from about 37700 to 58200 hz while running in 1hz increments.
> >  this allows for sync to video/tape/midi or whatever. or it allows for
the
> >  sample rate to be adjusted when receiving audio using rtp.
>
> Can the frequency be changed without stopping (no loss of sound)?

yes

> If so it is
> an interesting feature, but I am not sure if supported by ALSA.

perhaps it could be added?
in EASI every driver has a number of supported sample rates and an
associated pitch range.

--martijn


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a), some questions

[Takashi Iwai]

At Fri, 31 May 2002 11:38:41 +0100,
Martijn Sipkema wrote:
> 
> below is a message i sent earlier, but with the wrong email address:
> 
> ----
> 
> writing audiowerk driver (philips saa7146a), some questions
> 
> 
>  hi,
> 
>  i have finally been able to get the information i need to be able
>  to write a driver for the emagic audiowerk8 audio interface.
>  now since i am not an experienced kernel programmer and have
>  not even done audio programming (apart from midi), i have
>  some questions.
> 
>  - should i use the normal double buffered aproach or does having
>  more than 2 buffers have advantages?
 
most of pci drivers use a linear contigous buffer for pcm (per
stream).
the scatter-gather buffer is not supported yet on alsa (as a mid/high
level layer -- it would be possible if you write all on the low-level
layer).
the buffer is accessed directly via mmap as long as it's supported.


>  - what is normally called the latency of an audio interface for output?
>  is this the total size of the buffers or (in the case of double buffered
> io)
>  only one buffer? i'm thinking it is the total buffer size and this would
>  make using more than 2 buffers have a better latency/interrupt response
>  time ratio, right?

but if you have double buffer, isn't it difficult to handle mmap?
also i don't think double-buffer (that i'm not sure whether you mean
here "period" in the sense of alsa, or really double-buffering as in
graphics) leads to better latency.  of course my guess may be wrong. 

 
>  - should setting the buffer size and number be done on modules loading
>  or should it be possible to change it after that? the saa7146 doesn't need
>  contiguous memory since it has a mmu.
 
the buffer size and numbers are specified by each application.
at set-up stage, an application and driver commnucate with each other
to find the preferable condition.  the driver answers the hardware
restriction to the application which inquires the condition.
then the hardware is "prepared" actually, by calling prepare
callback.

in most cases, the hardawre restriction (condition) can be described
in snd_pcm_hardware_t struct, which is passed to the runtime instance
at open callback.  the struct contains most of important conditions,
such as supported formats, rates, channels, max buffers, etc.
also, you can define more complicated conditions, if necessary.


>  - where can i find documentation on writing alsa drivers? what would be
>  the best driver source to use for documentation?
 
hmm..  it depends on the hardware design...


>  - does alsa allow varipitch? i think the new rme cards are supposed to
>  have this feature and the audiowerk8 has it, i.e. it can change its
> sampling
>  rate from about 37700 to 58200 hz while running in 1hz increments.
>  this allows for sync to video/tape/midi or whatever. or it allows for the
>  sample rate to be adjusted when receiving audio using rtp.
 
basically no (at least not tested).  but i think it's not too
difficult to support it.  we can assign a control per pcm.
you'll need to change runtime->rate dynamically according to the
current rate, so that the tick interrupt handler calculates the time
properly.


>  - the audiowerk8 uses three dma channels: one for input and two for output.
>  should i just wake a process that is blocking on a read() from the input
> dma
>  interrupt or should i wait until all three dma channels are ready and then
>  unblock all read()/write() processes? should unblocking the processes be
>  done
>  from bottom half?

it's a job of alsa's high-level layer.
the lowlevel routines don't have to handle sleep()/wakeup().
just call snd_pcm_period_elapsed() in the interrupts routine when the
certain amount of samples have been processed.


Takashi

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a), some questions

[Martijn Sipkema]

> >  - should i use the normal double buffered aproach or does having
> >  more than 2 buffers have advantages?
>
> most of pci drivers use a linear contigous buffer for pcm (per
> stream).
> the scatter-gather buffer is not supported yet on alsa (as a mid/high
> level layer -- it would be possible if you write all on the low-level
> layer).
> the buffer is accessed directly via mmap as long as it's supported.
>
>
> >  - what is normally called the latency of an audio interface for output?
> >  is this the total size of the buffers or (in the case of double
buffered
> > io)
> >  only one buffer? i'm thinking it is the total buffer size and this
would
> >  make using more than 2 buffers have a better latency/interrupt response
> >  time ratio, right?
>
> but if you have double buffer, isn't it difficult to handle mmap?
> also i don't think double-buffer (that i'm not sure whether you mean
> here "period" in the sense of alsa, or really double-buffering as in
> graphics) leads to better latency.  of course my guess may be wrong.

i did not mean two buffers actually, perhaps the alsa term is period? with
double buffering i meant having the saa7146 interrupt at half buffer.

the saa7146 uses a single contiguous buffer, optionally using an mmu (so
then the buffer is not actually contiguous in physical memory).

thus, having more than two periods is advantageous?

> >  - should setting the buffer size and number be done on modules loading
> >  or should it be possible to change it after that? the saa7146 doesn't
need
> >  contiguous memory since it has a mmu.
>
> the buffer size and numbers are specified by each application.
> at set-up stage, an application and driver commnucate with each other
> to find the preferable condition.  the driver answers the hardware
> restriction to the application which inquires the condition.
> then the hardware is "prepared" actually, by calling prepare
> callback.
>
> in most cases, the hardawre restriction (condition) can be described
> in snd_pcm_hardware_t struct, which is passed to the runtime instance
> at open callback.  the struct contains most of important conditions,
> such as supported formats, rates, channels, max buffers, etc.
> also, you can define more complicated conditions, if necessary.
>

so if the application can set the buffer at set-up stage, it is best to
allocate
buffer memory at that time?

> >  - does alsa allow varipitch? i think the new rme cards are supposed to
> >  have this feature and the audiowerk8 has it, i.e. it can change its
> > sampling
> >  rate from about 37700 to 58200 hz while running in 1hz increments.
> >  this allows for sync to video/tape/midi or whatever. or it allows for
the
> >  sample rate to be adjusted when receiving audio using rtp.
>
> basically no (at least not tested).  but i think it's not too
> difficult to support it.  we can assign a control per pcm.
> you'll need to change runtime->rate dynamically according to the
> current rate, so that the tick interrupt handler calculates the time
> properly.

again, i am not (yet) familiar with alsa, so i am not sure what
runtime->rate is
or what you mean with the tick interrupt handler (where can i find
documentation
on this?), but i think 'pitch' is meant as a deviation from the nominal
sample rate
and setting a large deviation can be thought of as a bad dac/adc?

> >  - the audiowerk8 uses three dma channels: one for input and two for
output.
> >  should i just wake a process that is blocking on a read() from the
input
> > dma
> >  interrupt or should i wait until all three dma channels are ready and
then
> >  unblock all read()/write() processes? should unblocking the processes
be
> >  done
> >  from bottom half?
>
> it's a job of alsa's high-level layer.
> the lowlevel routines don't have to handle sleep()/wakeup().
> just call snd_pcm_period_elapsed() in the interrupts routine when the
> certain amount of samples have been processed.

is there any documentation on this?

--martijn




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a), some questions

[Takashi Iwai]

At Fri, 31 May 2002 14:05:20 +0100,
Martijn Sipkema wrote:
> 
> > >  - should i use the normal double buffered aproach or does having
> > >  more than 2 buffers have advantages?
> >
> > most of pci drivers use a linear contigous buffer for pcm (per
> > stream).
> > the scatter-gather buffer is not supported yet on alsa (as a mid/high
> > level layer -- it would be possible if you write all on the low-level
> > layer).
> > the buffer is accessed directly via mmap as long as it's supported.
> >
> >
> > >  - what is normally called the latency of an audio interface for output?
> > >  is this the total size of the buffers or (in the case of double
> buffered
> > > io)
> > >  only one buffer? i'm thinking it is the total buffer size and this
> would
> > >  make using more than 2 buffers have a better latency/interrupt response
> > >  time ratio, right?
> >
> > but if you have double buffer, isn't it difficult to handle mmap?
> > also i don't think double-buffer (that i'm not sure whether you mean
> > here "period" in the sense of alsa, or really double-buffering as in
> > graphics) leads to better latency.  of course my guess may be wrong.
> 
> i did not mean two buffers actually, perhaps the alsa term is period? with
> double buffering i meant having the saa7146 interrupt at half buffer.
 
then it's called "two periods per buffer" in alsa.

> the saa7146 uses a single contiguous buffer, optionally using an mmu (so
> then the buffer is not actually contiguous in physical memory).
 
ok, it's similar to trident or emu10k1, which uses also its own TLB.
for pcm, both of them use contigous memory buffer, though.

> thus, having more than two periods is advantageous?
 
let the choice left to application.
more periods would be more stable even for interrupts delay, but of
course would have longer latency.


> > >  - should setting the buffer size and number be done on modules loading
> > >  or should it be possible to change it after that? the saa7146 doesn't
> need
> > >  contiguous memory since it has a mmu.
> >
> > the buffer size and numbers are specified by each application.
> > at set-up stage, an application and driver commnucate with each other
> > to find the preferable condition.  the driver answers the hardware
> > restriction to the application which inquires the condition.
> > then the hardware is "prepared" actually, by calling prepare
> > callback.
> >
> > in most cases, the hardawre restriction (condition) can be described
> > in snd_pcm_hardware_t struct, which is passed to the runtime instance
> > at open callback.  the struct contains most of important conditions,
> > such as supported formats, rates, channels, max buffers, etc.
> > also, you can define more complicated conditions, if necessary.
> >
> 
> so if the application can set the buffer at set-up stage, it is best to
> allocate
> buffer memory at that time?
 
yes.  however, usually a chunk of memory is pre-allocated at the boot
time (i.e. when the module is loaded), to avoid possible memory
fragmentation.   you can find snd_pci_preallocate_buffer() is called
where the pcm is created via snd_pcm_new().


> > >  - does alsa allow varipitch? i think the new rme cards are supposed to
> > >  have this feature and the audiowerk8 has it, i.e. it can change its
> > > sampling
> > >  rate from about 37700 to 58200 hz while running in 1hz increments.
> > >  this allows for sync to video/tape/midi or whatever. or it allows for
> the
> > >  sample rate to be adjusted when receiving audio using rtp.
> >
> > basically no (at least not tested).  but i think it's not too
> > difficult to support it.  we can assign a control per pcm.
> > you'll need to change runtime->rate dynamically according to the
> > current rate, so that the tick interrupt handler calculates the time
> > properly.
> 
> again, i am not (yet) familiar with alsa, so i am not sure what
> runtime->rate is
> or what you mean with the tick interrupt handler (where can i find
> documentation
> on this?), but i think 'pitch' is meant as a deviation from the nominal
> sample rate
> and setting a large deviation can be thought of as a bad dac/adc?
 
there is a runtime instance for a pcm stream, and this holds the
informaton such as the current rate, channels, formats, etc.
there is no pitch parameter implemented in alsa, but this can be added
easily into the runtime instance, if inevitablly necessary.

alsa pcm engine invokes a timer interrupt to update the "tick", and
this tick is determined using the rate of the runtime instance.
if you change the rate value dynamically during playback, then the
tick interrupt will be wrongly scheduled, and leads to wrong detection
of under/overrun.


> > >  - the audiowerk8 uses three dma channels: one for input and two for
> output.
> > >  should i just wake a process that is blocking on a read() from the
> input
> > > dma
> > >  interrupt or should i wait until all three dma channels are ready and
> then
> > >  unblock all read()/write() processes? should unblocking the processes
> be
> > >  done
> > >  from bottom half?
> >
> > it's a job of alsa's high-level layer.
> > the lowlevel routines don't have to handle sleep()/wakeup().
> > just call snd_pcm_period_elapsed() in the interrupts routine when the
> > certain amount of samples have been processed.
> 
> is there any documentation on this?

not (yet)...  i once posted a very brief summary to alsa devel ML.
please check out the archive.


Takashi


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a), some questions

[Martijn Sipkema]

> there is a runtime instance for a pcm stream, and this holds the
> informaton such as the current rate, channels, formats, etc.
> there is no pitch parameter implemented in alsa, but this can be added
> easily into the runtime instance, if inevitablly necessary.

i don't think the audiowerk is the only card capable of varipitch, though
most cards don't support it, but it is a nice feature and since alsa is
supposed to be advanced... :)

> alsa pcm engine invokes a timer interrupt to update the "tick", and
> this tick is determined using the rate of the runtime instance.
> if you change the rate value dynamically during playback, then the
> tick interrupt will be wrongly scheduled, and leads to wrong detection
> of under/overrun.

shouldn't the driver detect under/overrun? would a soundcard with a
bad dac (as in not accurate) also cause problems?


--martijn






_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a), some questions

[Martijn Sipkema]

> > i don't think the audiowerk is the only card capable of varipitch,
though
> > most cards don't support it, but it is a nice feature and since alsa is
> > supposed to be advanced... :)
>
> many consumer chips support in fact, too, such as emu10k1, ymfpci,
> cs46xx (also trident?)  sbawe and gus have pcms using synth

so it will be added? the best would be to have a pitch range for every
nominal sample rate as in EASI
 http://www.emagic.de/english/support/easi/index.html )


> > > alsa pcm engine invokes a timer interrupt to update the "tick", and
> > > this tick is determined using the rate of the runtime instance.
> > > if you change the rate value dynamically during playback, then the
> > > tick interrupt will be wrongly scheduled, and leads to wrong detection
> > > of under/overrun.
> >
> > shouldn't the driver detect under/overrun?
>
> yes.  that's why i mentioned above.  if you don't change rate
> value in runtime instance, then the alsa driver tries to schedule tick
> interval as if it's not changed.  and this causes inconsistency
> between the real-playback and tick time, eventually leading to a bogus
> detection of under/overrun.

i am lost. a under/overrun could (should) be detected from the interrupt
handler
for the card dma channel (period interrupt), right? that would never fail.

> > would a soundcard with a bad dac (as in not accurate) also cause
> > problems?
>
> if the hardware is too inaccurate (e.g. accumulated error over more
> than HZ), then, yes.   but i don't think this may happen.

i am afraid i don't understand this and i don't now where i can find
documentation
on it. how do other driver writers do this? read the source? or an API
reference?
is there no overview on the architecture? reading driver source code is not
the
easiest or fastest way to understand what's going on, if it is at all
possible to
understand without knowledge of the specific hardware.

does hardware allow to have a device specific kernel driver with an
associated
device specific user-space part? this would be much easier to implement for
me
than an alsa kernel driver i think.

--martijn





_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a), some questions

[Bob Ham]

On Fri, 2002-05-31 at 11:38, Martijn Sipkema wrote:

>  i have finally been able to get the information i need to be able
>  to write a driver for the emagic audiowerk8 audio interface.

Did emagic give you information about the hardware, or is it from some
other source?

-- 
Bob Ham: bob@ham.org  http://pkl.net/~node/

My music: http://mp3.com/obelisk_uk
GNU Hurd: http://hurd.gnu.org/

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: Fw: writing audiowerk driver (philips saa7146a),some questions

[Martijn Sipkema]

> >  i have finally been able to get the information i need to be able
> >  to write a driver for the emagic audiowerk8 audio interface.
> 
> Did emagic give you information about the hardware, or is it from some
> other source?

Emagic pointed me to http://www.landamore.com/audiowerk.html
All the information i have is the driver and the philips SAA7146A
documentation. Although more information would help, this is at least
enough to get sound in/out the Audiowerk. I emailed the author of
this driver, but he has not (yet) replied.

--martijn


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm