22 Dec, 2015

1 commit

  • Stanton Controllers and Systems 1 (SCS.1) series is supported by ALSA
    scs1x driver. This driver just supports MIDI functionality. On the other
    hand, models in this series are based on OXFW971 and ALSA OXFW driver can
    support them.

    SCS.1 series has MIDI functionality to control its surface state such as
    LED lighting. When operating physical knobs and faders, the models
    generate MIDI messages. These MIDI messages are transferred by asynchronous
    transactions. These transactions are really model-specific and ALSA OXFW
    driver requires the functionality so as scs1x module implements.

    This commit adds scs1x layer as a preparation to merge scs1x driver to
    oxfw driver.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

15 Dec, 2015

1 commit

  • In ALSA firewire stack, drivers basically has no control elements. This
    is due to the fact that each model has own functionality even if they use
    the same communication chipset. Implementing all of the functionalities in
    kernel space unreasonably increases our efforts to maintain the stack. In
    most case, these functionalities can be implemented in userspace via Linux
    fw character devices.

    However, ALSA OXFW driver has control elements comes from old
    firewire-speakers driver. Adding the elements is in a file names as
    'oxfw-control.c', while the elements are really model-specific. The
    name is confusing because it gives an idea to handle control elements
    for all of OXFW-based models.

    This commit renames the file so that it's just for models supported by
    old firewire-speakers driver.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

18 Oct, 2015

1 commit

  • When committed to upstream, these four modules had wrong entries for
    Makefile. This forces them to be loadable modules even if they're set
    as built-in.

    This commit fixes this bug.

    Fixes: b5b04336015e('ALSA: fireworks: Add skelton for Fireworks based devices')
    Fixes: fd6f4b0dc167('ALSA: bebob: Add skelton for BeBoB based devices')
    Fixes: 1a4e39c2e5ca('ALSA: oxfw: Move to its own directory')
    Fixes: 14ff6a094815('ALSA: dice: Move file to its own directory')
    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

10 Dec, 2014

4 commits

  • This interface is designed for mixer/control application. By using this
    interface, an application can get information about firewire node, can
    lock/unlock kernel streaming and can get notification at starting/stopping
    kernel streaming.

    Signed-off-by: Takashi Sakamoto
    Acked-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     
  • This commit adds MIDI functionality with an assumption of 'if the device
    has MIDI comformant data channels in its stream formation, the device has
    one MIDI port'.

    When no streams have already started, MIDI functionality starts stream
    with current sampling rate.

    When MIDI functionality has already starts some streams and PCM
    functionality is going to start streams at different sampling rate,
    this driver stops streams once and changes sampling rate, then restarts
    streams for both PCM/MIDI substreams.

    Signed-off-by: Takashi Sakamoto
    Acked-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     
  • This commit adds proc interface to get information about stream
    formation. This commit also adds snd_oxfw_stream_get_current_formation()
    to get current stream formation.

    Signed-off-by: Takashi Sakamoto
    Acked-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     
  • OXFW970/971 may supports AV/C Stream Format Information Specification 1.1
    Working Draft (Apr 2005, 1394TA). By using this command, drivers can get to know
    stream formations which device supports.

    This commit adds 'EXTENDED STREAM FORMAT INFORMATION' command. This command
    has two subfunctions, 'SINGLE' and 'LIST'. Drivers can use 'SINGLE' subfunction
    to know/set current formation of AMDTP stream, Drivers can use 'LIST'
    subfunction to know an available formation of AMDTP stream in a certain sampling
    rate.

    But some devices don't implement the 'LIST' subfunction. So this commit uses
    an assumption that 'if they don't implement it, they don't change stream
    formation depending on current each sampling rate'. With this assumption, this
    driver generates formations for such devices by:
    1.getting current formation by SINGLE subfunction
    2.getting supported sampling rates
    3.applying current formation for all of supported sampling rates

    Followed commit implements a parser of this format information.

    Signed-off-by: Takashi Sakamoto
    Acked-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

30 Nov, 2014

4 commits