The channel mapping has been moved to hdspm.c, so it's no longer
available to userspace tools. For now, let's simply copy (duplicate) the
data and wait for a way to query this information from the driver.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Merged the work by Florian Faber that's distributed separately as
hdspmixer64.
Code taken from http://wiki.linuxproaudio.org/index.php/App:hdspmixer_64
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A one off string buffer overflow fixed by handling it properly with
string stream.
Signed-off-by: Georg Rudolph <georg.rudolph@schwaben.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Please note that LDFLAGS is the _wrong_ variable to pass libraries
with, automake tells you to use _LDADD for binaries and _LIBADD for
libraries, while autoconf wants them in the LIBS variable.
Signed-off-by: Diego 'Flameeyes' Pettenò <flameeyes@gmail.com>
From debian bug#450805:
We are using Hammerfall DSP cards. After booting, their audio output
remains silent until hdspmixer is started. No interaction in the GUI
of hdspmixer is necessary to unmute the first HDSP card; however,
further cards are only unmuted when activating the respective GUI
page ("2", "3"). Apparently, hdspmixer does some automatic
initialization of the card when activating the page.
Since we'd like to have a fully automatic startup, the following
patch activates the page for each existing card on startup, thereby
initializing them. There are surely more elegant solutions, but this
patch is tested and solves the problem for us.
This patch changes .iface to SNDRV_CTL_ELEM_IFACE_MIXER whre _PCM or
_HWDEP was used in controls that are not associated with a specific PCM
(sub)stream or hwdep device, and changes some controls that got
inconsitent .iface values due to copy+paste errors. Furthermore, it
makes sure that all control that do use _PCM or _HWDEP use the correct
number in the .device field.
