- 18 May, 2023 2 commits
-
-
Oswald Buddenhagen authored
This workaround fails to address the underlying problem, which is actually wholly self-made. Subsequent patches will fix it. This reverts commit 56385a12. Signed-off-by:
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-2-oswald.buddenhagen@gmx.deSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Oswald Buddenhagen authored
... to snd_emu10k1_pcm_init_voice(). This makes the code arguably less convoluted. Signed-off-by:
-
- 17 May, 2023 18 commits
-
-
Oswald Buddenhagen authored
32-bit platforms don't like these. As we're actually dealing with constants, factor out the calculations and pass them in as additional arguments. To keep the call sites clean, wrap the actual functions in macros which generate the arguments. Fixes: bb5ceb43 ("ALSA: emu10k1: fix non-zero mixer control defaults in highres mode") Fixes: 1298bc97 ("ALSA: emu10k1: enable bit-exact playback, part 1: DSP attenuation") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202305171622.jKTovBvy-lkp@intel.com/Reported-by:
Linux Kernel Functional Testing <lkft@linaro.org> Reported-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Closes: https://lore.kernel.org/r/CA+G9fYsShNP=LALHdMd-Btx3PBtO_CjyBNgpStr9fPGXNbRvdg@mail.gmail.comSigned-off-by:
-
Oswald Buddenhagen authored
Shrink the {in,out}put_source arrays and their data type to what is actually necessary. To be still on the safe side, add some static asserts. Signed-off-by: -
Oswald Buddenhagen authored
Unlike the other models, this is actually a distinct card, rather than an E-MU 1010 with different "dongles". It is stereo only, and supports no ADAT (there is no trace of ADAT in the manual, switching the output mode to ADAT has no effect, and switching the input mode to ADAT just breaks input (presumably ... my only ADAT source is the card's output)). Signed-off-by:
-
Oswald Buddenhagen authored
This card has rather different inputs/outputs due to switching from the AudioDock to the MicroDock. Signed-off-by:
-
Oswald Buddenhagen authored
The more card models are handled separately, the more code duplication this saves. add_emu1010_source_mixers() is factored out the save duplication in a later commit. Signed-off-by:
-
Oswald Buddenhagen authored
... and move it to the mixer init, as it's logically part of it. As a side effect, this fixes the initial values of the input destination mixer controls, which would have previously remained at "Silent" despite different defaults. This didn't really matter, though, as ALSA state restoration would hide that bug beyond first use. Note that this completely does away with clearing the output routing registers, as it was rather pointless - we just programmed the FPGA (resetting it first if necessary), so everything is zeroed anyway (that's documented by Xilinx, and as further evidence, some of the loops terminated too early, and we didn't bother clearing the high channels of the input routes at all, all with no observed adverse effects). As a drive-by, this also fixes some capture channel defaults - any EMU_SRC_*2 isn't a sensible value in 1x clock mode. Signed-off-by:
-
Oswald Buddenhagen authored
It returned zero even if the value had changed. Signed-off-by:
-
Oswald Buddenhagen authored
Instead of hard-coding the card-specific arrays and their sizes in each function, use a more data-driven approach. As a drive-by, also hide the unavailable I2S input destinations on the 1616 cardbus card. Also as a drive-by, use more assignments at variable declaration for brevity. This also removes the pointless masking of kctl.private_value. Signed-off-by:
-
Oswald Buddenhagen authored
Define arrays of strings instead of snd_kcontrol_new. While at it, move the E-MU source & destination enum defs next to their hardware defs, which is a lot more logical and will come in handy in a followup commit. And add some static asserts to verify that the array sizes match. This also applies the compactization from the previous commit to the destination registers. While reshuffling the arrays anyway, switch the order of the HAMOA_DAC & HANA_SPDIF output destinations for the 1010 card, so they follow a more regular pattern. This should have no functional impact. The code is somewhat de-duplicated by the extraction of add_ctls(). Signed-off-by:
-
Oswald Buddenhagen authored
Use macros to avoid duplication. Arguably, this is somewhat less legible, but future additions would grow this part of the file to completely unmanageable dimensions. The EMU*_COMMON_TEXTS macros will save duplication in a future commit; I pulled them ahead to reduce churn. While rewriting the tables anyway, rearrange them such that each card's strings and registers are adjacent. Also, add some static asserts to verify that the array sizes match. Signed-off-by:
-
Oswald Buddenhagen authored
- Use bit fields in struct snd_emu_chip_details - Use shorts in the E-MU routing register arrays Signed-off-by:
-
Oswald Buddenhagen authored
Saves a bit of code duplication. Signed-off-by:
-
Oswald Buddenhagen authored
Many registers are meaningless for stereo slaves and the extra voices. This patch cleans up these unnecessary register writes. snd_emu10k1_playback_{trigger,stop}_voice() is not called for stereo slaves any more. snd_emu10k1_playback_prepare_voice() is renamed to snd_emu10k1_playback_unmute_voice(), as this better reflects its remaining function. It's not called for the extra voices any more. Accordingly, snd_emu10k1_playback_mute_voice() is factored out from snd_emu10k1_playback_stop_voice(), and is called selectively as well. This doesn't add conditionals which would avoid initializing sub-registers, as that wouldn't pull its weight. Signed-off-by: -
Oswald Buddenhagen authored
We now enable ints even before triggering, and disable them only after stopping - otherwise there is a race condition we may plausibly run into when we pause/resume near the end of the buffer. Updating the epcm->running flag is moved the same way, as it affects the *_pointer() functions, which are called by the interrupt handler. Also, factor these out to own functions, for clarity. For multi-channel, the extra voice is now triggered after all regular voices - we wouldn't want to receive an int before all channels have passed the period boundary. Signed-off-by:
-
Oswald Buddenhagen authored
We initialize them at card init and don't touch them later, so there is no need to reset them again at voice start. Signed-off-by:
-
Oswald Buddenhagen authored
We (rightfully) don't enable the envelope engine for PCM voices, so any related setup is entirely pointless - the EMU8K documentation makes that very clear, and the fact that the various open drivers all use different values to no observable detriment pretty much confirms it. The remaining initializations are regrouped for clarity. Signed-off-by:
-
Oswald Buddenhagen authored
The mixer structures were filled in two places: on driver init, and when the devices are opened. The latter made the former pointless, so we remove the former. This implies that mixer dumps may now return all zeroes, which is OK, as restoring them is meaningless as well. Things were even weirder for the (generally unused) secondary sends: Some of the initialization loops were forgotten when support for Audigy was added, thus creating the technically illegal state of multiple sends being routed to the same FX accumulator (though it apparently doesn't matter when the amount is zero). The global multi-channel init used some rather bizarre values for the secondary sends, and the init on open actually forgot to re-initialize them. We now use a not really more useful, but simpler formula. The direct register init was also bogus. This doesn't really matter, as the value is overwritten when a voice comes into use, but still. Signed-off-by:
-
Min-Hua Chen authored
SNDRV_CTL_ELEM_TYPE_* are type of snd_ctl_elem_type_t, we have to __force cast them to int when comparing them with int to fix the following sparse warnings. sound/core/control_compat.c:203:14: sparse: warning: restricted snd_ctl_elem_type_t degrades to integer sound/core/control_compat.c:205:14: sparse: warning: restricted snd_ctl_elem_type_t degrades to integer sound/core/control_compat.c:207:14: sparse: warning: restricted snd_ctl_elem_type_t degrades to integer sound/core/control_compat.c:209:14: sparse: warning: restricted snd_ctl_elem_type_t degrades to integer sound/core/control_compat.c:237:21: sparse: warning: restricted snd_ctl_elem_type_t degrades to integer sound/core/control_compat.c:238:21: sparse: warning: restricted snd_ctl_elem_type_t degrades to integer sound/core/control_compat.c:270:21: sparse: warning: restricted snd_ctl_elem_type_t degrades to integer sound/core/control_compat.c:271:21: sparse: warning: restricted snd_ctl_elem_type_t degrades to integer Signed-off-by:
Min-Hua Chen <minhuadotchen@gmail.com> Link: https://lore.kernel.org/r/20230516223806.185683-1-minhuadotchen@gmail.comSigned-off-by:
-
- 16 May, 2023 1 commit
-
-
Oswald Buddenhagen authored
The voice volume is a raw fractional multiplier that can't actually represent 1.0. To still enable real pass-through, we now set the volume to 0.5 (which results in no loss of precision, as the FX bus provides fractional values) and scale up the samples in DSP code. To maintain backwards compatibility with existing configuration files, we rescale the values in the mixer controls. The range is extended upwards from 0xffff to 0x1fffd, which actually introduces the possibility of specifying an amplification. There is still a minor incompatibility with user space, namely if someone loaded custom DSP code. They'll just get half the volume, so this doesn't seem like a big deal. Signed-off-by:
-
- 15 May, 2023 10 commits
-
-
Oswald Buddenhagen authored
Fractional multiplication with the maximal value 2^31-1 causes some tiny distortion. Instead, we want to multiply with the full 2^31. The catch is of course that this cannot be represented in the DSP's signed 32 bit registers. One way to deal with this is to encode 1.0 as a negative number and special-case it. As a matter of fact, the SbLive! code path already contained such code, though the controls never actually exercised it. A more efficient approach is to use negative values, which actually extend to -2^31. Accordingly, for all the volume adjustments we now use the MAC1 instruction which negates the X operand. The range of the controls in highres mode is extended downwards, so -1 is the new zero/mute. At maximal excursion, real zero is not mute any more, but I don't think anyone will notice this behavior change. ;-) That also required making the min/max/values in the control structs signed. This technically changes the user space interface, but it seems implausible that someone would notice - the numbers were actually treated as if they were signed anyway (and in the actual mixer iface they _are_). And without this change, the min value didn't even make sense in the first place (and no-one noticed, because it was always 0). Tested-by:
Jonathan Dowland <jon@dow.land> Signed-off-by:
-
Oswald Buddenhagen authored
The microphone capture device is a feature of the AC97 codec, so its availability should be coupled to the presence of that codec. Signed-off-by:
-
Oswald Buddenhagen authored
The E-MU cards don't try very hard to be Sound Blasters. All sound I/O goes through the Hana FPGA, thus making the regular extin/out controls useless. Still showing them just serves to clutter up the interface and confuse the user. Signed-off-by:
-
Oswald Buddenhagen authored
User space could pass arbitrary ranges, which were uncritically accepted. This could lead to table lookups out of range. I don't think that this is a security issue, as it only allowed someone with CAP_SYS_ADMIN to crash the kernel, but still. Setting an invalid translation mode will also be rejected now. That did no harm, but it's still better to detect errors. Signed-off-by:
-
Oswald Buddenhagen authored
The default value needs to be scaled. Signed-off-by:
-
Oswald Buddenhagen authored
- Pull ahead all fixed allocations, so we don't rely on the semi- dynamic ones not crossing the arbitrarily determined limit - Use an enum for the fixed allocations - Stop arbitrarily wasting registers on unexplained "reservations" - Don't reserve two regs for the master volume control - it's mono Signed-off-by:
-
Oswald Buddenhagen authored
Unlike in snd_emu10k1_ptr_write(), we don't need to keep the value's bits in place, so we can save one shift. Signed-off-by:
-
Oswald Buddenhagen authored
Avoids some code duplication. Signed-off-by:
-
Oswald Buddenhagen authored
Rather than applying masks to the provided values, make assertions about them being valid - otherwise we'd just try to paper over bugs. Signed-off-by:
-
Oswald Buddenhagen authored
The idea to encode the bitfield manipulation in the register address is quite clever, but doing that by hand is ugly and error-prone. So derive it automatically from the mask instead. Macros cannot #define other macros, so we now declare enums instead. This also adds macros for decoding the register definitions. These will be used by later commits. Signed-off-by:
-
- 12 May, 2023 7 commits
-
-
Oswald Buddenhagen authored
Instead of using lots of instructions to mix wet and dry signals, simply skip over the whole code block if tone control is disabled. This also allows us doing away with the "shadow" playback channels. Tested-by:
-
Oswald Buddenhagen authored
Evidently, the channel delay bug exists in all E-MU cards; it's in the Hana FPGA program, and was never fixed. Note that the implementation is somewhat lazy - to localize the code paths, we actually waste a GPR and a DSP instruction by keeping two delay registers for the same physical source. Signed-off-by:
-
Oswald Buddenhagen authored
Instead of spending lots of instructions on masking and transplanting the sign bit, sidestep the issue by replacing the last bit shift with a wrapping addition to self. Solution stolen from kX-project, after I pondered other ideas first. Also, the function really doesn't need to return a constant int value. Signed-off-by:
-
Oswald Buddenhagen authored
Presumably, JDC added the seemingly superfluous indirection over the temporary register because without it he'd get only zero readings. However, switching the X and Y operands (or using EMU32 as the A operand in the temporary load) works just fine. Presumably a DSP bug? The original code was also actually buggy, though: both channels used the left volume control. Signed-off-by:
-
Oswald Buddenhagen authored
There is no apparent reason for the massive code duplication. Signed-off-by:
-
Oswald Buddenhagen authored
It controls the whole surround set, so stereo can't work. As a consequence, only the left channel was paid attention to. Signed-off-by:
-
Oswald Buddenhagen authored
These ports are unused on these cards. Signed-off-by:
-
- 08 May, 2023 2 commits
-
-
Jaroslav Kysela authored
Introduce SNDRV_PCM_INFO_PERFECT_DRAIN and SNDRV_PCM_HW_PARAMS_NO_DRAIN_SILENCE flags to fully control the filling of the silence samples in the drain ioctl. Actually, the configurable silencing is going to be implemented in the user space [1], but drivers (hardware) may not require this operation. Those flags do the bidirectional setup for this operation: 1) driver may notify the presence of the perfect drain 2) user space may not require the filling of the silence samples to inhibit clicks If we decide to move this operation to the kernel space in future, the SNDRV_PCM_INFO_PERFECT_DRAIN flag may handle this situation without double "silence" processing (user + kernel space). The ALSA API should be universal, so forcing the behaviour (modifying of the ring buffer with any samples) for the drain operation is not ideal. [1] https://lore.kernel.org/alsa-devel/20230502115010.986325-1-perex@perex.cz/ [ fixed a typo in comment by tiwai ] Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20230502115536.986900-1-perex@perex.czSigned-off-by:
-
Oswald Buddenhagen authored
- Fix mixer source port names. These will require some users to re-adjust their mixer settings, which seems acceptable: - The S/PDIF port is on the main 1010 card, not the 0202 daughter card - The 1616m CardBus card has all inputs on the dock, so there is no point in specifying it - Conversely, the 1010 card has "dispersed" inputs, so say where the ADAT port is, consistently with the S/PDIF port - The 1616m CardBus card is actually named E-MU 02 (due to the headphone output jack it has) - Fix capitalization of "E-MU" Signed-off-by:
-
