This post of mine to the alsa forum is relevant to the above question.
It seems the RME linux driver has changed since alsa 1.0.15, and the changes have caused my code to stop working.
Any hints ?
---------------------------------------------------------------------------------------------------------------------------------------------
See original thread below first.
What I've since discovered is that the code works fine using the module(driver) from alsa 1.0.15 and the RME card, but fails using the module from alsa 1.0.18+. Besides the module, any version of alsa can be used for the alsa library and utils and it works still.
I have not tried the same tests with the Asus STX Xonar card yet.
So, either some problem has crept into alsa after 1.0.15 that causes this issue, or something on the API has changed so that my usage is no longer correct. Any hints ? What changes to the mmap API ?
Note the controls for the RME card change in alsamixer with the change in alsa module. Some of the clocking options have been re-arranged, and name of the card has also changed (for the same hardware).
Usage parameters mentioned below. I am registering and using an async callback. I can provide source code if that helps.
If required, how would I go about using an old 1.0.15 module in a later alsa system ? I tried ./configure in the alsa-driver-1.0.15 directory and that fails; things seem to have changed so much since with kernel source etc. The tests above (working) with the 1.0.15 module were done with an older kernel too.
PS: Compiling with 1.0.27 alsa I get a warning about deprecated call "snd_pcm_sw_params_set_xfer_align". What should now be done instead ?
Hope someone can help !
Bruce
> Subject: Problem with async callbacks stopping
>
> Hi,
>
> I've combed the web for a possible solution to my problem and I can't seem
> to find anything germane, so here goes !
> I'm hoping someone can lead me in the right direction, as this has become
> very frustrating.
>
> Some History:
>
> A few years ago I wrote a dedicated app specific record/playback application
> on alsa 1.0.15, running on a Sun 64bit machine running Suse 10.
> The soundcard was a professional 32 channel RME DSP Hammerfall.
> It used an async receive callback and memory mapping (mmap). Eventually I
> got it all working smoothly. It performs both playback (on 2 channels
> 31/32 or 63/64, depending on whether sample rate was 96k or 48k) and
> sampling on up to 32 channels simultaneously. I have a comment in the code
> that I had troubles getting both receive and transmit callbacks working at
> the same time, so I simply ended up calling the transmit routine from the
> receive callback (the rate was the same) and that worked fine.
>
> Recently I have had need to re-visit this project. The Sun machine has died,
> but the RME soundcard lives on.
> It was installed on a new HP 64bit machine, now running Suse 11 which has
> alsa 1.0.18.
>
> Running my original program (recompiled with the new alsa libs), I can get
> about 1s of audio out. The program then hangs. On closer investigation, it
> seems the async receive callback runs for a while, then simply stops.
> I can get sounds out using aplay, but they are skipping and distorted.
> Pulse audio has been disabled by simply removing the alsa-pulse.conf file in
> /etc.
> I downloaded and installed the lastest alsa 1.0.27, but the symptoms were
> the same. In desperation I also tried the original alsa 1.0.15, but that
> didn't help either.
> All other soundcards are disabled. There is on-board sound (both Intel, and
> on the Nvidea video card for HDMI) so I can't physically remove them.
>
> Thinking there may be some problem with the old soundcard hardware, a modern
> Asus Xonar STX was fitted. I have modified my application to use only 2
> channels, and interleaved samples (the STX hardware doesn't support
> non-interleaved at the low level, and I'm trying to avoid using plughw to be
> sure I'm getting exactly what I want). The card appears as card 2 for some
> reason. That's OK, just use hw:2,0 instead.
> Encouragingly, aplay seems to behave OK, playing 48k wav files through plug.
> Unfortunately, after all this effort, the callbacks seem to die in pretty
> much the same way as they did with the RME card. I can see I get up to about
> 49000 samples (or roughly 1s at 48k sample rate). Then no more callbacks.
> No xrun errors are reported in the callbacks that do happen.
>
> The application architecture is quite similar in structure to the alsa
> example code pcm.c.
>
> I can give you /proc or other outputs as required, but as I'm actually
> communicating with the soundcard I'm not sure that's much help.
> I tweaked the hardware parameters passed in hwparams as required so as not
> to get an error back from the card driver that something wasn't supported.
> Currently using on the STX: SND_PCM_ACCESS_MMAP_INTERLEAVED, 48k, 2
> channels, SND_PCM_FORMAT_S32_LE.
>
> On the RME I was using: SND_PCM_ACCESS_MMAP_NONINTERLEAVED, 48k/96k,
> 64/32 channels, SND_PCM_FORMAT_S32_LE
>
> It could be the code, but it used to work on the Sun.....
> It coud be the soundcard, but the RME worked on the Sun and neither the RME
> or the STX work on the HP....
> It could be the HP, but how ?
>
> I'm not sure what to do now ?
>
> A basic polled method doesn't lend itself well to handling 32 channels, and
> would result in double buffer handling.
