1. 16 Feb, 2010 1 commit
    • Sebastien Alaiwan's avatar
      ALSA: USB MIDI support for Access Music VirusTI · d39e82db
      Sebastien Alaiwan authored
      Here's a patch that adds MIDI support through USB for one of the Access
      Music synths, the VirusTI.
      
      The synth uses standard USBMIDI protocol on its USB interface 3, although
      it does signal "vendor specific" class. A magic string has to be sent on
      interface 3 to enable the sending of MIDI from the synth (this string was
      found by sniffing usb communication of the Windows driver). This is all
      my patch does, and it works on my computer.
      
      Please note that the synth can also do standard usb audio I/O on its
      interfaces 2&3, which already works with the current snd-usb-audio driver,
      except for the audio input from the synth. I'm going to work on it when I
      have some time.
      Signed-off-by: default avatarSebastien Alaiwan <sebastien.alaiwan@gmail.com>
      Signed-off-by: Clemens Ladisch <clemens@ladisch.de> (cosmetics, list terminator)
      Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
      d39e82db
  2. 11 Feb, 2010 1 commit
  3. 02 Feb, 2010 1 commit
  4. 01 Feb, 2010 2 commits
  5. 27 Jan, 2010 1 commit
    • Jaroslav Kysela's avatar
      ALSA: pcm_native - fix runtime->boundary calculation · 7910b4a1
      Jaroslav Kysela authored
      The code in pcm_lib updating runtime->hw_ptr_interrupt expects
      that runtime->boundary is divisible with runtime->period_size.
      Thanks are going to Clemens Ladisch for the notice.
      
      Fix the runtime->boundary calculation using buffer_size * period_size
      as base and find a least common multiple for 32bit platforms when
      the expression might overflow.
      Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
      7910b4a1
  6. 26 Jan, 2010 1 commit
    • Jaroslav Kysela's avatar
      ALSA: pcm_lib - return back hw_ptr_interrupt · e7636925
      Jaroslav Kysela authored
      Clemens Ladisch noted for hw_ptr_removal in "cleanup & merge hw_ptr
      update functions" commit:
      
      "It is possible for the status/delay ioctls to be called when the sound
      card's pointer register alreay shows a position at the beginning of the
      new period, but immediately before the interrupt is actually executed.
      (This happens regularly on a SMP machine with mplayer.)  When that
      happens, the code thinks that the position must be at least one period
      ahead of the current position and drops an entire buffer of data."
      
      Return back the hw_ptr_interrupt variable. The last interrupt pointer
      is always computed from the latest hw_ptr instead of tracking it
      separately (in this case all hw_ptr checks and modifications might
      influence also hw_ptr_interrupt and it is difficult to keep it
      consistent).
      Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
      e7636925
  7. 21 Jan, 2010 2 commits
  8. 18 Jan, 2010 2 commits
  9. 13 Jan, 2010 1 commit
  10. 08 Jan, 2010 6 commits
  11. 07 Jan, 2010 4 commits
  12. 28 Dec, 2009 3 commits
  13. 27 Dec, 2009 4 commits
  14. 26 Dec, 2009 1 commit
  15. 25 Dec, 2009 2 commits
    • Takashi Iwai's avatar
      Merge branch 'fix/hda' into topic/hda · 15e7f8b9
      Takashi Iwai authored
      15e7f8b9
    • Wu Fengguang's avatar
      ALSA: hda - HDMI sticky stream tag support · ef18bede
      Wu Fengguang authored
      When we run the following commands in turn (with
      CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0),
      
      	speaker-test -Dhw:0,3 -c2 -twav  # HDMI
      	speaker-test -Dhw:0,0 -c2 -twav  # Analog
      
      The second command will produce sound in the analog lineout _as well as_
      HDMI sink. The root cause is, device 0 "reuses" the same stream tag that
      was used by device 3, and the "intelhdmi - sticky stream id" patch leaves
      the HDMI codec in a functional state. So the HDMI codec happily accepts
      the audio samples which reuse its stream tag.
      
      The proposed solution is to remember the last device each azx_dev was
      assigned to, and prefer to
      1) reuse the azx_dev (and hence the stream tag) the HDMI codec last used
      2) or assign a never-used azx_dev for HDMI
      
      With this patch and the above two speaker-test commands,
      HDMI codec will use stream tag 8 and Analog codec will use 5.
      
      The stream tag used by HDMI codec won't be reused by others, as long
      as we don't run out of the 4 playback azx_dev's. The legacy Analog
      codec will continue to use stream tag 5 because its device id is 0
      (this is a bit tricky).
      Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ef18bede
  16. 24 Dec, 2009 8 commits