Fórum » Last.fm Client Support

Linux 1.0.0b high pitched/fast playback

 
  • Linux 1.0.0b high pitched/fast playback

    I'm finding that playback with the lastfm player is
    too fast. I had a similar problem in the past with
    Realplayer after upgrading to my current soundcard
    but it has disappeared in newer versions.

    Fedora Core 5, alsa 1.0.11-4.rc2
    Sound card uses the snd_ice1724 module, which wants
    everything going through hw0:0 to be 32 bit LE.
    Adjusting the internal clock rate with alsamixer
    has an effect, but even when the speed seems to be
    right there's a strong distortion/warbling.

    • floogy disse...
    • Usuário
    • Ago 17 2006, 21h31
    You can set rate 44100 in your ~/.asoundrc. Please refer to the alsa wiki.

  • .asoundrc is really horribly documented and it's not
    entirely clear how to do it this way. As far as I can
    tell it's done via plugins, and they aren't presented
    as an option in the radio menu.

    Anyway, I don't think this is the issue, the card's
    clockspeed can be controlled via alsamixer. The following
    are taken while running with it set to 44100:

    [ian@atlas ~]$ cat /proc/asound/card0/pcm0p/sub0/hw_params
    access: RW_INTERLEAVED
    format: S32_LE
    subformat: STD
    channels: 2
    rate: 44100 (44100/1)
    period_size: 512
    buffer_size: 4096
    tick_time: 4000
    [ian@atlas ~]$ cat /proc/asound/card0/pcm0p/sub0/sw_params
    tstamp_mode: NONE
    period_step: 1
    sleep_min: 0
    avail_min: 512
    xfer_align: 512
    start_threshold: 512
    stop_threshold: 2147483647
    silence_threshold: 0
    silence_size: 2147483647
    boundary: 1073741824

    This sounds too fast and high pitched. Reducing the
    clock rate to 22050 produces something that sounds
    the right speed (and the timing is right, I timed 55s
    between 'Johnny Come Lately's on The Eagles - New
    Kid in Town with the player and a local copy), but
    is very noisy. I think 16 bit samples are being
    submitted and interpreted as 32 bit.

  • Okay, I added the following to
    void RtApiAlsa :: tickStream() in src/rtaudioplayback/rtaudio/RtAudio.cpp;

    fwrite(buffer, 4 * channels, stream_.bufferSize, stdout);

    (Just before the following)
    // Write samples to device in interleaved/non-interleaved format.
    if (stream_.deInterleave[0]) {
    void *bufs[channels];
    size_t offset = stream_.bufferSize * formatBytes(format);
    for (int i=0; i<channels; i++)
    bufs = (void *) (buffer + (i * offset));
    err = snd_pcm_writen(handle[0], bufs, stream_.bufferSize);
    }

    The output (WARNING, it's 11MB) from a few seconds of this playing the first thing that came up on my recommended station (Joy Division) is at http://www.srcf.ucam.org/~ibm21/lastfm_out.raw. It should be 32_LE (which it seems to be) 44100Hz 2 channels (which I'm not sure of - I don't know what the original should sound like).

  • The following is the output resulting from running with __RTAUDIO_DEBUG__ enabled (doesn't seem to be any additional output when playing):
    Running on: "en_GB"

    RtApiAlsa: dump hardware params just after device open:

    ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
    FORMAT: S32_LE
    SUBFORMAT: STD
    SAMPLE_BITS: 32
    FRAME_BITS: [64 256]
    CHANNELS: [2 8]
    RATE: [8000 192000]
    PERIOD_TIME: (10 2048000]
    PERIOD_SIZE: [2 16384]
    PERIOD_BYTES: [64 524288]
    PERIODS: [2 1024]
    BUFFER_TIME: (20 4096000]
    BUFFER_SIZE: [4 32768]
    BUFFER_BYTES: [64 262144]
    TICK_TIME: 4000

    RtApiAlsa: dump hardware params after installation:

    ACCESS: RW_INTERLEAVED
    FORMAT: S32_LE
    SUBFORMAT: STD
    SAMPLE_BITS: 32
    FRAME_BITS: 64
    CHANNELS: 2
    RATE: 44100
    PERIOD_TIME: (11609 11610)
    PERIOD_SIZE: 512
    PERIOD_BYTES: 4096
    PERIODS: (7 8)
    BUFFER_TIME: (92789 92790)
    BUFFER_SIZE: 4092
    BUFFER_BYTES: 32736
    TICK_TIME: 4000

    RtApiAlsa: dump software params after installation:

    start_mode: DATA
    xrun_mode: NONE
    tstamp_mode: NONE
    period_step: 1
    sleep_min: 0
    avail_min: 512
    xfer_align: 512
    silence_threshold: 0
    silence_size: 2147483647
    boundary: 2145386496
    Initialising Search Extension
    Initialising Search GUI
    Initialising Sidebar Extension
    Initialising Sidebar GUI
    Initialising UserInfo Extension


    Any RtAudio gurus about?

  • I have tried several ways of setting rate in .asoundrc and all of them still sound funky (and not in a good way). I should add that I've never managed to fix anything using .asoundrc, most of the documentation for which seems to be magic workarounds
    for particular problems. Regardless, something funny is happening in RtAudio.

    Anyone else using a 24bit or 96/192kHz soundcard, either successfully or with problems?

  • So: downloaded rtaudio-3.0.3 and took a CD rip (actually, had been encoded as ogg, but that shouldn't matter for this purpose).
    Was: 16bit signed int, two channels, 44.1kHz

    Used sox to produce three .raw files, without changing rate or number of channels:
    16bit signed int.
    32bit signed int.
    32bit float.

    Built the rtaudio test programs, tried ./configure --with-alsa first, repeated later with ./configure --with-oss. Tried the test/play_raw program, changing the used data type between the above three types. In each configuration the corresponding .raw played correctly and the others did not (as a point of interest, playing s32 as f32 was the least distorted of these cross-overs). The situation was the same for oss builds.

    Conclusion: RtAudio 3.0.3 can play fine to my card at 44100Hz
    in either OSS or ALSA. I can also confirm that in RTAudioPlayback::initAudio() the client appears to be asking for RTAUDIO_SINT32 and 44100 sample rate.

    Took the 3.0.3 RtAudio.cpp, RtAudio.h, RtError.h and dropped them into the lastfm trunk. Client built without any suspicious warnings, loads fine, but segfaults on attempting to play. Haven't time at the minute to do any more.

  • Won.

    Educated guess, I'd had a look at rtaudioplayback.cpp after reading another thread (about switching to OSS, which didn't work for me), and discovered the client was asking for 32S. Given the above (where rtaudio can be seen doing the work to convert to the native type), I wondered why it was done that way. It seems it shouldn't be; playback now works. Now to find out why connecting is so much slower under Linux than Windows.

    Index: src/rtaudioplayback/rtaudioplayback.cpp
    ===================================================================
    --- src/rtaudioplayback/rtaudioplayback.cpp (revision 2115)
    +++ src/rtaudioplayback/rtaudioplayback.cpp (working copy)
    @@ -212,6 +212,8 @@
    format = RTAUDIO_SINT16;
    }

    + format = RTAUDIO_SINT16;
    +
    m_audio = new RtAudio( card, channels, 0, 0, format, sampleRate, &bufferSize, nBuffers, api );
    }
    catch ( RtError &error )
    Index: bin/lastfm_debug.sh
    ===================================================================
    --- bin/lastfm_debug.sh (revision 2115)
    +++ bin/lastfm_debug.sh (working copy)
    @@ -1,4 +1,4 @@
    #!/bin/sh
    RUNDIR=`dirname $0`
    export LD_LIBRARY_PATH=$RUNDIR:$LD_LIBRARY_PATH
    -`$RUNDIR/LastFM_debug $*`
    +$RUNDIR/LastFM_debug $*

    • floogy disse...
    • Usuário
    • Set 13 2006, 16h41
    060913 16:35:27 - 46912541953008 - L3
    Using format RTAUDIO_SINT16

    060913 16:35:27 - 46912541953008 - L1
    Initialising RtAudio failed. RtAudio error type: 7 Message: RtApi: unable to open specified device(s) with given stream parameters:
    RtApiAlsa: error setting sample rate (44100) on device (hw:CK804,0): Invalid argument.


    060913 16:35:27 - 46912541953008 - L3
    Trying to load extension: libextension_metadata.so


    Unfortunatly that didn't work for me :((

  • Your card probably does a fixed sample rate then (this is quite common and likely to be 48000, something to do with ac97). Ideally alsa plugs do both type and rate conversion if the hardware doesn't support what's requested. RtAudio does sample type conversion (because the naive approach is trivial), but not rate conversion. Hence using OSS (which can then be fed through plugs) works.

    I'd guess "sampleRate = 48000;" where I added "format = RTAUDIO_SINT16;" would let you use Alsa output, but of course your sound would be transposed.

    I'd speculate my problem was: RtAudio reports back that the card takes 32bit signed, the client thinks, okay, I'll take a 44.1kHz 32bit signed interface then, and proceeds to submit the output from the mp3 decoder (44.1kHz 16bit signed). Result: ~playback at 44.1kHz of every other sample from one channel (other channel disappears below noise floor).

    • floogy disse...
    • Usuário
    • Set 13 2006, 23h07
    I'll try that too, later, because I think it's important to know why the RtAudio implementation fails on some (a lot of ?) cards.

    So, assuming, that that's the reason why it crashes on play: Would it be possible to implement sth. to get rid of these problems, by adding detection code to the RtAudio source, to recognize these affected cards, and do something approriate?

    ALSA can handle the rate too, to sample it down to 44100 Hz .

  • Better to have RtAudio open a plug interface to Alsa, then it could open at the rate it wanted and Alsa would do the resampling. But writing that requires a good knowledge of RtAudio and probably the Alsa API.

    Edit:
    Of course the way to find out what's going on is to uncomment:
    #define __RTAUDIO_DEBUG__
    at the end of:
    trunk/src/rtaudioplayback/rtaudio/RtAudio.h

    Edit more:
    You may need to apply the change to lastfm_debug.sh from the above diff too, otherwise the shell is being asked to /run/ stdout. If that doesn't work with your version of bash it'd be simplest to fudge the correct command instead.

    • floogy disse...
    • Usuário
    • Set 15 2006, 20h07
    $ bin/lastfm_debug.sh
    bin/lastfm_debug.sh: line 4: bin/LastFM_debug: No such file or directory

    Hmm.. my svn/trunk didn't build a LastFM_debug binary.
    Nevertheless the build produces the logfiles.


    $ bin/lastfm.sh
    Running on: "C"

    RtApiAlsa: dump hardware params just after device open:

    ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
    FORMAT: S16_LE
    SUBFORMAT: STD
    SAMPLE_BITS: 16
    FRAME_BITS: [32 96]
    CHANNELS: [2 6]
    RATE: [48000 96000]
    PERIOD_TIME: (31 341334)
    PERIOD_SIZE: [3 16384]
    PERIOD_BYTES: [32 131072]
    PERIODS: [1 1024]
    BUFFER_TIME: (31 341334)
    BUFFER_SIZE: [3 16384]
    BUFFER_BYTES: [32 65536]
    TICK_TIME: 4000

    RtApiAlsa: error setting sample rate (44100) on device (hw:CK804,0): Invalid argument.


    RtApi: unable to open specified device(s) with given stream parameters:
    RtApiAlsa: error setting sample rate (44100) on device (hw:CK804,0): Invalid argument.


    Initialising Search Extension
    Initialising Search GUI
    Initialising Sidebar Extension
    Initialising Sidebar GUI
    Initialising UserInfo Extension


    Note: on crash (play) there is no additional output on stdout.
    changing rate 44100 to 48000 in .asoundrc didn't help.

    • floogy disse...
    • Usuário
    • Set 15 2006, 20h44
    Hmmm... I changed src/rtaudioplayback/rtaudioplayback.cpp
    to this:

    174
    175 void
    176 RTAudioPlayback::initAudio()
    177 {
    178 int channels = 2;
    179 int nBuffers = 8;
    180 int bufferSize = 512;
    181 // int sampleRate = 44100;
    182 int sampleRate = 48000;
    183 try
    184 {
    185 RtAudio::RtAudioApi api = RtAudio::UNSPECIFIED;
    186 RtAudioFormat format = RTAUDIO_SINT16;
    187 m_audio = new RtAudio();
    188



    That works! But it's too quick and there are clicks and interruptions, of course. I can't set the buffer to avoid the clicks and downsample the rate to 44100 by alsa in .asoundrc. That doesn't work :(

    [rate]
    gerhard@ubuntu:~/download/Radio/Last.FM/svn/trunk$ bin/lastfm.sh Running on: "C"

    RtApiAlsa: dump hardware params just after device open:

    ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
    FORMAT: S16_LE
    SUBFORMAT: STD
    SAMPLE_BITS: 16
    FRAME_BITS: [32 96]
    CHANNELS: [2 6]
    RATE: [48000 96000]
    PERIOD_TIME: (31 341334)
    PERIOD_SIZE: [3 16384]
    PERIOD_BYTES: [32 131072]
    PERIODS: [1 1024]
    BUFFER_TIME: (31 341334)
    BUFFER_SIZE: [3 16384]
    BUFFER_BYTES: [32 65536]
    TICK_TIME: 4000

    RtApiAlsa: dump hardware params after installation:

    ACCESS: RW_INTERLEAVED
    FORMAT: S16_LE
    SUBFORMAT: STD
    SAMPLE_BITS: 16
    FRAME_BITS: 32
    CHANNELS: 2
    RATE: 48000
    PERIOD_TIME: (10666 10667)
    PERIOD_SIZE: 512
    PERIOD_BYTES: 2048
    PERIODS: 9
    BUFFER_TIME: 96000
    BUFFER_SIZE: 4608
    BUFFER_BYTES: 18432
    TICK_TIME: 4000

    RtApiAlsa: dump software params after installation:

    start_mode: DATA
    xrun_mode: NONE
    tstamp_mode: NONE
    period_step: 1
    sleep_min: 0
    avail_min: 512
    xfer_align: 512
    silence_threshold: 0
    silence_size: 0
    boundary: 5188146770730811392
    Initialising Search Extension
    Initialising Search GUI
    Initialising Sidebar Extension
    Initialising Sidebar GUI
    Initialising UserInfo Extension



    Now, I'm able to choose between ck804:0 and ck804:2 in the audio options under radio! It shows my soundcards!


    Querying audio devices
    Device nums: 3
    Device name: "hw:CK804,0"

    RtApiAlsa: pcm device (hw:CK804,1) doesn't handle output!

    Device name: "hw:CK804,1"

    RtApiAlsa: pcm device (hw:CK804,2) doesn't handle input!

    Device name: "hw:CK804,2"


    Unfortunately the sound is transposed, and I think due to this there are some clicks and interruptions (this might be a buffer problem too 1) ). Any hints how to solve this? Will this be fixed by he last.FM Staff in the future?

    1) bitstream problem: resyncing..

    Editado por floogy em Set 15 2006, 21h33
    • floogy disse...
    • Usuário
    • Set 15 2006, 20h52
    pheidippides said:
    Better to have RtAudio open a plug interface to Alsa, then it could open at the rate it wanted and Alsa would do the resampling. But writing that requires a good knowledge of RtAudio and probably the Alsa API.


    I'm sure that would be the solution of this dilemma! I suggest to the developers to fix this in RtAudio, to make use of the alsa plugs like plug:hw:0 or plug:dmix or whatever!

  • floogy said:
    RATE: [48000 96000]

    So your card doesn't support 44.1kHz, hence
    not being able to set the rate.


    Unfortunately the sound is transposed, and I think due to this there are some clicks and interruptions (this might be a buffer problem too 1) ).

    I think you're right about the clicks being a buffer problem, it would hopefully disappear at the right playback rate. Oddly, playing at twice the rate mine didn't display clicks, but there might be frame size issues or they were simply hidden beneath the noise.


    pheidippides said:

    Better to have RtAudio open a plug interface to Alsa, then it could open at the rate it wanted and Alsa would do the resampling. But writing that requires a good knowledge of RtAudio and probably the Alsa API.

    I'm sure that would be the solution of this dilemma! I suggest to the developers to fix this in RtAudio, to make use of the alsa plugs like plug:hw:0 or plug:dmix or whatever!


    I think it's more complex than specifying plughw:0,0 as the device to open. Looking at the Alsa API suggests the application needs to do the work to set up the plug chain itself, which means it then needs keep a record of the plug chain and close it properly afterwards.

    That said, there is a point in RtAudio.cpp (don't have the source to hand at the moment, it's a function that opens the device for playback) where snd_pcm_open is called with the device name; a simple and hackish solution would be to try substituting plughw for whatever hw interface would otherwise be opened here, but I doubt it would help. (On one card I still get playback, on another it fails to open the device, neither of those cards has your problem)

    As for dmix, I don't think I've seen it work on my Fedora Core 5, despite having Alsa 1.0.11 (FC5 packaged) where it should work automagically. I possibly haven't used the right incantations though. (The real tragedy is my card can actually do hardware mixing)

    • floogy disse...
    • Usuário
    • Set 15 2006, 23h35
    Maybe it's possible to use the JACK API to handle the sample rate:
    http://www.music.mcgill.ca/~gary/rtaudio/index.html#multi

    My card does actually do hardwaremixing, too, but you can't use the hardwaremixing with alsa. But I set up dmix in .asoundrc :


    #Begin http://alsa.opensrc.org/OSS+and+dmix
    #default control device is my card
    #(as it does anyway, without .asoundrc)
    ctl.!default {
    type hw
    card 0
    rate 44100
    }


    pcm.dmixer { #this virtual device does the mixing of
    type dmix #the various signals
    ipc_key 1024
    slave {
    pcm "hw:0,0"
    period_time 0
    period_size 1024
    buffer_size 4096
    rate 44100
    #rate 48000
    }
    bindings {
    0 0
    1 1
    }
    }


    pcm.!default { #this means that applications use the mixer
    type plug #by default, so you can hear everything
    slave.pcm "dmixer"
    }
    #End http://alsa.opensrc.org/OSS+and+dmix


    I'm not a programmer at all, though. Therefor I didn't understand why it would be that complex to implement all these things into last.FM (oss, alsa, jack support, and support of the alsa plug api).

  • I haven't tested this yet, but it appears that the bit of the Alsa API I was looking at (for setting up plugs), is more of an internal thing, and all the app needs to do is pass the correct chain (don't know if that's the right terminology) to snd_pcm_open. plughw is a specific device, and won't work in all situations, but modifying the passed string to plug:'devicename' seems to be right. (the quotes need to be there)

    To confirm whether this is the right track, find out what device name is being used then try runnning aplay on some audio file:
    $ aplay -D plug:\'devicename\' -r 44100 somefile.wav
    (and check the reported playback rate is 44.1, funny stuff happens occasionally.

    • floogy disse...
    • Usuário
    • Set 18 2006, 16h29
    $ aplay -D plug:hw:0 -r 44100 ~/out.wav
    Playing WAVE '/home/gerhard/out.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo


    BTW in your .asoundrc you can define which plug is used by default, so that you don't need to pass the right string (as far as my understanding)
    pcm.!default { #this means that applications use the mixer
    type plug #by default, so you can hear everything
    slave.pcm "dmixer"
    }


    But how can one achieve, that RtAudio (i.e. last.FM) can handle these alsa plugs?

    As I mentioned before: I'm not a programer at all, but I would appreciate if I'll see last.FM supporting JACK!

  • Can I assume that just -D plug hw:0,0 wouldn't work for you at 44.1? Yep, I know the -D isn't needed in this aplay example, but what I'm trying to work out is whether it's sufficient just to construct this plug string at the last minute.

    The following is a bit messy but may actually be the right fix:

    Index: src/rtaudioplayback/rtaudio/RtAudio.cpp
    ===================================================================
    --- src/rtaudioplayback/rtaudio/RtAudio.cpp (revision 2115)
    +++ src/rtaudioplayback/rtaudio/RtAudio.cpp (working copy)
    @@ -3785,6 +3785,11 @@

    // I'm not using the "plug" interface ... too much inconsistent behavior.
    const char *name = devices_[device].name.c_str();
    + std::string usename("plug:\"");
    + fprintf(stdout,"%s\n",name);
    + usename += name;
    + usename += "\"";
    + fprintf(stdout,"%s\n",usename.c_str());

    snd_pcm_stream_t alsa_stream;
    if (mode == OUTPUT)
    @@ -3795,7 +3800,7 @@
    int err;
    snd_pcm_t *handle;
    int alsa_open_mode = SND_PCM_ASYNC;
    - err = snd_pcm_open(&handle, name, alsa_stream, alsa_open_mode);
    + err = snd_pcm_open(&handle, usename.c_str(), alsa_stream, alsa_open_mode);
    if (err < 0) {
    sprintf(message_,"RtApiAlsa: pcm device (%s) won't open: %s.",
    name, snd_strerror(err));
    ===================================================================

    Core idea: the app only has to request the right chain and alsa will set it up and filter it through. There may be some way to detect devices like dmix, but it may be simpler just to add it as a fixed entry before the others. Not sure whether that would work. I'm operating well outside my own understanding.

    • floogy disse...
    • Usuário
    • Set 22 2006, 13h44

    [solved, partly] nvidia nforce (ck804) crash on play

    Hello pheidippides,

    Your patch works 100% (Hooray!),

    You was able to figure this out,so can you, please, also make the JACK API available, which is already prepared in the RtAudio source?

    Like I mentioned before: Unfortunately I'm not a ptrogrammer at all, and can't do that on my own :-(


    Running on: "C"

    RtApiAlsa: dump hardware params just after device open:

    ACCESS: MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX RW_INTERLEAVED RW_NONINTERLEAVED
    FORMAT: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW A_LAW IMA_ADPCM S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
    SUBFORMAT: STD
    SAMPLE_BITS: [4 64]
    FRAME_BITS: [4 640000]
    CHANNELS: [1 10000]
    RATE: [4000 4294967295)
    PERIOD_TIME: (31 341334)
    PERIOD_SIZE: (0 1466018367)
    PERIOD_BYTES: (0 4294967295)
    PERIODS: (0 4294967295]
    BUFFER_TIME: [1 4294967295]
    BUFFER_SIZE: [1 1466015503]
    BUFFER_BYTES: [1 4294967295]
    TICK_TIME: 4000

    RtApiAlsa: dump hardware params after installation:

    ACCESS: RW_INTERLEAVED
    FORMAT: S16_LE
    SUBFORMAT: STD
    SAMPLE_BITS: 16
    FRAME_BITS: 32
    CHANNELS: 2
    RATE: 44100
    PERIOD_TIME: (21333 21334)
    PERIOD_SIZE: (940 941)
    PERIOD_BYTES: (3760 3764)
    PERIODS: 16
    BUFFER_TIME: (341315 341316)
    BUFFER_SIZE: 15052
    BUFFER_BYTES: 60208
    TICK_TIME: 4000

    RtApiAlsa: dump software params after installation:

    start_mode: DATA
    xrun_mode: NONE
    tstamp_mode: NONE
    period_step: 1
    sleep_min: 0
    avail_min: 940
    xfer_align: 940
    silence_threshold: 0
    silence_size: 0
    boundary: 4236761349448794112
    Initialising Search Extension
    Initialising Search GUI
    Initialising Sidebar Extension
    Initialising Sidebar GUI
    Initialising UserInfo Extension




    $ lsof /dev/snd/*
    COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
    gnome-vol 12238 gerhard 14u CHR 116,7 12848 /dev/snd/controlC0
    gnome-vol 21431 gerhard 14u CHR 116,7 12848 /dev/snd/controlC0
    gnome-vol 21440 gerhard 14u CHR 116,7 12848 /dev/snd/controlC0
    LastFM 23865 gerhard mem CHR 116,5 12621 /dev/snd/pcmC0D0p
    LastFM 23865 gerhard 15u CHR 116,5 12621 /dev/snd/pcmC0D0p


    But unfortunately it blocks the device completely :-(( :


    $ aplay -Dplug:dmix ~/out.wav
    ALSA lib pcm_dmix.c:819:(snd_pcm_dmix_open) unable to open slave
    aplay: main:544: audio open error: Device or resource busy


    How can one make use of the alsa dmix plugin?

  • I've never got dmix working on my machine, despite a fairly up to date ALSA and copy-pasting lots of example .asoundrc files. I'd imagine usename="plug:dmix"; instead of the usename += "\""; etc. stuff would be sufficient if you had it set up. The proper way to do it is to try and detect the available (non-hardware) devices, failing that to have the RtAudio ALSA code test for the existence of a dmix device when it's getting properties for the others.

    Not a clue about Jack, sorry. Briefly tried compiling for Jack (worked) and running (failed, library problem which shouldn't be happening as far as I can tell).

    • floogy disse...
    • Usuário
    • Set 23 2006, 11h15
    I'd imagine usename="plug:dmix"; instead of the usename += "\""; etc. stuff would be sufficient if you had it set up.

    Thanks that works!

    $ lsof /dev/snd/*
    COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
    gnome-vol 8653 gerhard 14u CHR 116,7 14175 /dev/snd/controlC0
    LastFM 12465 gerhard mem CHR 116,5 13970 /dev/snd/pcmC0D0p
    LastFM 12465 gerhard 15u CHR 116,5 13970 /dev/snd/pcmC0D0p
    LastFM 12465 gerhard 16r CHR 116,2 13538 /dev/snd/timer
    LastFM 12471 gerhard mem CHR 116,5 13970 /dev/snd/pcmC0D0p
    LastFM 12471 gerhard 15u CHR 116,5 13970 /dev/snd/pcmC0D0p
    aplay 12974 gerhard mem CHR 116,5 13970 /dev/snd/pcmC0D0p
    aplay 12974 gerhard 3r CHR 116,2 13538 /dev/snd/timer
    aplay 12974 gerhard 4u CHR 116,5 13970 /dev/snd/pcmC0D0p


    I compiled RtAudio for Jack too, and had also problems with lacking libs or something like that :(

    I hope the staff will add fully chooseable alsa plugs/devices, and the ability to switch between alsa, oss and jack, because RtAudio seems to be able to handle that with the appropriate changes in the codebase.

    pheidippides, can you please advice me how to make a propper diff to the tree, against the svn/trunk, to document the changes in a 'patch style' manner?

    BTW: I also noticed an other issue with LastFM beta:
    It doesn't stop playing if one quit the LastFM player. One have to killal LastFM (therefor 5 LastFM instances found by lsof, I guess).

    And last, but not least: I think the player highly needs his linux-build BugTrackingSystem (BTS).

    • floogy disse...
    • Usuário
    • Set 23 2006, 11h40
    pheidippides said:
    I've never got dmix working on my machine, despite a fairly up to date ALSA and copy-pasting lots of example .asoundrc files.


    dmix should activated by default by alsa >= 1.0.11 I think.
    On Ubuntu 6.06 Dapper I can use it e.g. with aplay -Dplug:dmix ~/sample.wav out of the box.

    I now have a ~/.asoundrc which also handles dsnoop and asym as a full duplex alsa-sharing device.

    http://alsa.opensrc.org/OSS+and+dmix worked for me.

    My ~/.asoundrc



    # ALSA library configuration file ~/.asoundrc

    # Include settings that are under the control of asoundconf(1).
    # (To disable these settings, comment out this line.)
    </home/gerhard/.asoundrc.asoundconf>

    pcm.card0 {
    type hw
    card 0
    }

    ctl.card0 {
    type hw
    card 0
    }

    ctl.!default {
    type hw
    card 0
    rate 44100
    }

    #Begin http://alsa.opensrc.org/OSS+and+dmix
    #default control device is my card
    #(as it does anyway, without .asoundrc)
    ctl.!default {
    type hw
    card 0
    rate 44100
    }


    pcm.dmixer { #this virtual device does the mixing of
    type dmix #the various signals
    ipc_key 1024
    slave {
    pcm "hw:0,0"
    period_time 0
    period_size 1024
    buffer_size 4096
    rate 44100
    #rate 48000
    }
    bindings {
    0 0
    1 1
    }
    }


    pcm.!default { #this means that applications use the mixer
    type plug #by default, so you can hear everything
    slave.pcm "dmixer"
    }
    #End http://alsa.opensrc.org/OSS+and+dmix

    pcm.dsnooper {
    type dsnoop
    ipc_key 2048
    slave.pcm pcm.card0
    bindings {
    0 0
    1 1
    }
    }
    pcm.duplex {
    type asym
    playback.pcm dmixer
    capture.pcm dsnooper
    }

    pcm.dsp0 {
    type plug
    slave.pcm dmixer
    }

    pcm.!default {
    type plug
    slave.pcm swmixer
    }

    pcm.swmixer {
    type dmix
    ipc_key 1234
    slave {
    pcm 'hw:0,0'
    period_time 0
    period_size 1024
    buffer_size 4096
    rate 44100
    }
    }


    pcm.dsp0 { type plug slave.pcm "dmix" }
    pcm.dsp1 { type plug slave.pcm "dmix" }
    pcm.dsp2 { type plug slave.pcm "dmix" }
    pcm.dsp3 { type plug slave.pcm "dmix" }
    pcm.dsp4 { type plug slave.pcm "dmix" }
    pcm.dsp5 { type plug slave.pcm "dmix" }
    pcm.dsp6 { type plug slave.pcm "dmix" }
    pcm.dsp7 { type plug slave.pcm "dmix" }
    pcm.dsp8 { type plug slave.pcm "dmix" }
    pcm.dsp9 { type plug slave.pcm "dmix" }
    pcm.dsp10 { type plug slave.pcm "dmix" }
    pcm.dsp11 { type plug slave.pcm "dmix" }
    pcm.dsp12 { type plug slave.pcm "dmix" }
    pcm.dsp13 { type plug slave.pcm "dmix" }
    pcm.dsp14 { type plug slave.pcm "dmix" }
    pcm.dsp15 { type plug slave.pcm "dmix" }


    #JACK http://gentoo-wiki.com/HOWTO_Jack#Any_application_that_uses_ALSA

    pcm.jackplug {
    type plug
    slave { pcm "jack" }
    }

    pcm.jack {
    type jack
    playback_ports {
    0 alsa_pcm:playback_1
    1 alsa_pcm:playback_2
    }
    capture_ports {
    0 alsa_pcm:capture_1
    1 alsa_pcm:capture_2
    }
    }
    #EndJACK


    aplay -L detects with that ~/.asoundrc these devices and plugs:



    $ aplay -L PCM list:
    hw {
    @args.0 CARD
    @args.1 DEV
    @args.2 SUBDEV
    @args.CARD {
    type string
    default {
    @func getenv
    vars {
    0 ALSA_PCM_CARD
    1 ALSA_CARD
    }
    default {
    @func refer
    name 'defaults.pcm.card'
    }
    }
    }
    @args.DEV {
    type integer
    default {
    @func igetenv
    vars {
    0 ALSA_PCM_DEVICE
    }
    default {
    @func refer
    name 'defaults.pcm.device'
    }
    }
    }
    @args.SUBDEV {
    type integer
    default {
    @func refer
    name 'defaults.pcm.subdevice'
    }
    }
    type hw
    card $CARD
    device $DEV
    subdevice $SUBDEV
    }
    plughw {
    @args.0 CARD
    @args.1 DEV
    @args.2 SUBDEV
    @args.CARD {
    type string
    default {
    @func getenv
    vars {
    0 ALSA_PCM_CARD
    1 ALSA_CARD
    }
    default {
    @func refer
    name 'defaults.pcm.card'
    }
    }
    }
    @args.DEV {
    type integer
    default {
    @func igetenv
    vars {
    0 ALSA_PCM_DEVICE
    }
    default {
    @func refer
    name 'defaults.pcm.device'
    }
    }
    }
    @args.SUBDEV {
    type integer
    default {
    @func refer
    name 'defaults.pcm.subdevice'
    }
    }
    type plug
    slave.pcm {
    type hw
    card $CARD
    device $DEV
    subdevice $SUBDEV
    }
    }
    plug {
    @args.0 SLAVE
    @args.SLAVE {
    type string
    }
    type plug
    slave.pcm $SLAVE
    }
    shm {
    @args.0 SOCKET
    @args.1 PCM
    @args.SOCKET {
    type string
    }
    @args.PCM {
    type string
    }
    type shm
    server $SOCKET
    pcm $PCM
    }
    tee {
    @args.0 SLAVE
    @args.1 FILE
    @args.2 FORMAT
    @args.SLAVE {
    type string
    }
    @args.FILE {
    type string
    }
    @args.FORMAT {
    type string
    default raw
    }
    type file
    slave.pcm $SLAVE
    file $FILE
    format $FORMAT
    }
    file {
    @args.0 FILE
    @args.1 FORMAT
    @args.FILE {
    type string
    }
    @args.FORMAT {
    type string
    default raw
    }
    type file
    slave.pcm null
    file $FILE
    format $FORMAT
    }
    null {
    type null
    }
    cards 'cards.pcm'
    front 'cards.pcm.front'
    rear 'cards.pcm.rear'
    center_lfe 'cards.pcm.center_lfe'
    side 'cards.pcm.side'
    surround40 'cards.pcm.surround40'
    surround41 'cards.pcm.surround41'
    surround50 'cards.pcm.surround50'
    surround51 'cards.pcm.surround51'
    surround71 'cards.pcm.surround71'
    iec958 'cards.pcm.iec958'
    spdif 'cards.pcm.iec958'
    modem 'cards.pcm.modem'
    phoneline 'cards.pcm.phoneline'
    dmix 'cards.pcm.dmix'
    dsnoop 'cards.pcm.dsnoop'
    card0 {
    type hw
    card 0
    }
    dmixer {
    type dmix
    ipc_key 1024
    slave {
    pcm 'hw:0,0'
    period_time 0
    period_size 1024
    buffer_size 4096
    rate 44100
    }
    bindings {
    0 0
    1 1
    }
    }
    dsnooper {
    type dsnoop
    ipc_key 2048
    slave.pcm 'pcm.card0'
    bindings {
    0 0
    1 1
    }
    }
    duplex {
    type asym
    playback.pcm dmixer
    capture.pcm dsnooper
    }
    dsp0 {
    type plug
    slave.pcm dmix
    }
    default {
    type plug
    slave.pcm swmixer
    }
    swmixer {
    type dmix
    ipc_key 1234
    slave {
    pcm 'hw:0,0'
    period_time 0
    period_size 1024
    buffer_size 4096
    rate 44100
    }
    }
    dsp1 {
    type plug
    slave.pcm dmix
    }
    dsp2 {
    type plug
    slave.pcm dmix
    }
    dsp3 {
    type plug
    slave.pcm dmix
    }
    dsp4 {
    type plug
    slave.pcm dmix
    }
    dsp5 {
    type plug
    slave.pcm dmix
    }
    dsp6 {
    type plug
    slave.pcm dmix
    }
    dsp7 {
    type plug
    slave.pcm dmix
    }
    dsp8 {
    type plug
    slave.pcm dmix
    }
    dsp9 {
    type plug
    slave.pcm dmix
    }
    dsp10 {
    type plug
    slave.pcm dmix
    }
    dsp11 {
    type plug
    slave.pcm dmix
    }
    dsp12 {
    type plug
    slave.pcm dmix
    }
    dsp13 {
    type plug
    slave.pcm dmix
    }
    dsp14 {
    type plug
    slave.pcm dmix
    }
    dsp15 {
    type plug
    slave.pcm dmix
    }
    jackplug {
    type plug
    slave {
    pcm jack
    }
    }
    jack {
    type jack
    playback_ports {
    0 alsa_pcm:playback_1
    1 alsa_pcm:playback_2
    }
    capture_ports {
    0 alsa_pcm:capture_1
    1 alsa_pcm:capture_2
    }
    }


  • Turns out I needed format S32_LE in the slave{} section and that this necessitates I use plug:dmixer when using aplay to test.

    However I can confirm that if I do that and set usename="plug:dmixer" (as above) then lastfm works happily and can play simultaneously with other apps. The 'plug:' probably isn't necessary for lastfm to use dmixer for anyone as:
    1. The dmix device mixes everything to the same rate. If you've got the wrong dmix rate it will never work, plug or no plug. If you've got the right rate it doesn't matter what your starting rate was.
    2. RtAudio can do the sample type conversion (which is what I need plug for with aplay).

    $ svn diff
    In any directory in your working copy (preferably at the top level, so do it from the directory containing 'trunk') will produce a unified format diff.

    You only have to look at the miles of OS X crash logs in the "Linux & Mac Betas" thread to realise that a proper bugzilla is desperately needed.

Usuários anônimos não podem postar mensagens. É preciso fazer login ou criar uma conta para postar nos fóruns.