Each preset can have a different level meter setting (FS samples for
OVR, release rate, minimum level and so on).
These settings were not saved/restore to/from the on-disk file. This
patch adds the missing functionality.
Unfortunately, the current on-disk format is a 1:1 binary dump from
memory without any header information. In other words, this commit will
break backward compatibility with older hdspmixers, that is, new preset
files cannot be read by older versions of hdspmixer. However, we can
still read the old mix files and save them in the new format.
I hence bumped the version, so users know to re-create their files after
upgrading to 1.11.
Bug discovered by Raphaël Doursenaud from ematech.fr.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When running with more than one card, it isn't obvious which card is
shown.
Store the ALSA cardname in the corresponding class and show it in the
window title upon switching cards.
Also, don't show "(null)" but "(unsaved)" in case the user hasn't
selected a preset file.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some cards (like multiface) have more physical output ports than
playback ports, mostly because of additional headphones out.
For those cards, the old abstraction model of channels_input and
channels_output doesn't fit, so let's introduce channels_output.
Of course, channels_output is always 2*max_dest at the given speed_mode
(SS/DS/QS), so one could extend this idea, store all destination
settings in channels_output[3] (one for each speed mode) and rip off the
massive code duplication for setting maxdest or max_dest respectively.
Note that dest_map_whatever_speed_mode's array size indirectly defines
the right value for channels_output (read: even more unwanted
redundancy)
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When selecting preset 6 or 7 on AES(32), hdspmixer has caused a segfault
due to indirect out of bound access on the destination label array.
The amount of destinations is the number of physical stereo
pairs, so it's usually half the channel count, in some cases one more if
there are additional headphone jacks.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, hdsp and hdspm use different ioctls. Consequently, the metering
is wrong. To avoid code duplication, use pointers to the corresponding
struct members.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If three (or more) RME cards are installed in one box, hdspmixer will
try to open a non-existing 4th card, causing an error in snd_ctl_open
and finally terminates itself.
cards[] is a static array, and one must not read beyond the last
element. The solution is far from elegant, however, it's a rather
unintrusive change.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The copyright list got longer, so we need more vertical space.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Code provided by Fredrik Lingvall <fredrik.lingvall@gmail.com>
It seems the PCIe (AES) and PCI (AES32) versions behave the same, so we
can kill two birds with one stone.
Signed-off-by: Adrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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>
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.