ALSA Makes My Head Hurt

[NeddySeagoon]

Team,

Here's the story. I have two sound cards, both Intel HDA.
Using VLC, I can play 44.1kHz sample rate material over the analogue card, card 1, and 48kHz sample pate material over my video card, card 0.
So all the bits work.

I need to get sample rate conversion working so I only need to use HDMI
Further, there is a long time bug in in the digital output driver, that chops off the first few seconds of output when the stream is opened. The fix for that is to use dmix and play silence all the time.
I have a wee ditty in /etc/local.d that does that.

startpage.com is not being my friend. I've found lots of things that don't work.

My /home and /etc go back to 2003, maybe slightly earlier, so I've cleared out all the alsa related guff that I can see and don't have an /etc/asound.conf or a ~/.asoundrc

Pulseaudio is not an option.

I know what I want and that it involves dmix and sample rate conversion but what to put into /etc/asound.conf ?

-- edit --

Code: Select all

$ cat /etc/local.d/play_silence.start
#!/bin/bash

# Play silence forever so we don't miss the first few sec of sound. 
aplay -c2 -r48000 -fS16_LE < /dev/zero &

# The kernel option does not seem to fix it

but running that by hand gets me

Code: Select all

$ sudo  /etc/local.d/play_silence.start 
ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.2.8-r1/work/alsa-lib-1.2.8/src/pcm/pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave

but that would be the build location in tmpfs ...

Some progress ... maybe ..

Code: Select all

$ cat .asoundrc
pcm.dmixer {
	type dmix
	ipc_key 1234
	ipc_key_add_uid true # Needed ?
	ipc_perm 0666
	slave {
		format S16_LE
		pcm "hw:0,3"
                period_time 0
                period_size 1024
                buffer_size 4096
                rate 48000
	}
        bindings {
                0 0
                1 1
        }
}

# Whatever ctl magic thing
ctl.dmixer {
	type hw
	card 0
}

pcm.!default {
        type plug
        slave.pcm "dmixer"
}

The mixing and sample rate conversion in operational but the result is broken up sound output, whatever the source material sample rate.

[szatox]

Well, admins tend to waste a lot of time on stupid stuff that just fixes itself after reboot, so how 'bout starting with a nuclear option this time?

Like in: delete all configuration related to alsa and reinstall it to pull the maintainer's configs in place instead of trying to write it yourself?
The package's default configs are pretty sane, and tend to just work. However, the ebuild is pretty sane too, and portage will not helpfully force the provided bits on you.
You might need to reindex your audio cards afterwards, chances are your current config is the only reason your video device is the default output.

I mean, sure, DIY is cool, but alsa's neither critical nor very dynamic (in terms of configuration changes), and its hard to find any documentation regarding its config files so given an opportunity I'd rather put my energy somewhere else.

[Goverp]

This is "any advice short of actual help", as I've no idea! But FWIW:

Once upon a time, alsa came with alsaconf or somesuch that wrote a sensible configuration. That seems to have died; presumably like other packages it's supposed to be self-configuring. Well, on my HDA stuff in my AMDGPU graphics card, that doesn't appear to be the case, nor for my old but OK multi-output sound/MIDI card. It seems more to be a case of using the least configured generic setup, a bit like BIOS using VGA mode - guaranteed to work but missing all the features of better stuff.

When I look at my sound card, I guess using alsa tools (I forget, it's a while since I played with this stuff) I see lots of interesting hardware - mixers, filters, probably echo devices, again I forget. What ought to exist is a graphics (or better ncurses with ASCII art) GUI to simulate a patchboard and plugable set of controls such as dials, knobs and switches to wire the bits up. I got as far as some drawings on the back of a scrap of paper before more important things got in the way. I looked on the web and didn't find much, but that was a while ago. Maybe there's something useful lurking in https://www.alsa-project.org/wiki/Applications

[szatox]

Goverp, I think you're looking for JACK.
Unfortunately, I doubt upgrading from broken ALSA to JACK would do the trick for Neddy... JACK still uses ALSA under the hood, so it better be working first.

[NeddySeagoon]

szatox,

Yep all the bits work, I just need the magic to put them together.

44.1kHz material -> analogue hardware directly works.
48kHz material -> video card hardware works.

dmix and sample rate conversion to video card is a disaster, which is what I want to work.

[Anon-E-moose]

Code: Select all

$ cat .asoundrc
pcm.dmixer {
	type dmix
	ipc_key 1234
#	ipc_key_add_uid true # Needed ?
#	ipc_perm 0666
	slave {
#		format S16_LE
		pcm "hw:0,3"
                period_time 0
                period_size 1024
                buffer_size 4096
                rate 48000
	}
        bindings {
                0 0
                1 1
        }
}

# Whatever ctl magic thing
ctl.dmixer {
	type hw
	card 0
}

pcm.!default {
        type plug
        slave.pcm "dmixer"
}

What does this do (some things commented out)

[NeddySeagoon]

Anon-E-moose,

That doesn't change anything.

[Anon-E-moose]

Only other thing I know is just trial and error.

https://alsa.opensrc.org/Dmix has a lot of info, not sure how much might be applicable.

[NeddySeagoon]

For those that come after me ...

The documentation, which is either old or very old says

Code: Select all

                period_time 0
                period_size 1024
                buffer_size 4096 

but

Code: Select all

# speaker-test -Dhdmi:HDMI -c 2 uses
#Periods = 4
#was set period_size = 262144
#was set buffer_size = 1048576

so the period_size and buffer_size I've been using are far too small.
The working assumption is that speaker-test has a better idea of how it works than I do :)

After some trial an error. I've ended up with

Code: Select all

# Works for local sources
                period_size  131072  # 262144 # not 1024
                buffer_size  524288  # 1048576 # not 4096
#                period_time 0

Which is half the values that speaker-test used.

Sound is still broken up on youtube but that fixes my media collection.

[Anon-E-moose]

https://www.alsa-project.org/wiki/FramesPeriods

A frame is equivalent of one sample being played, irrespective of the number of channels or the number of bits. e.g.

1 frame of a Stereo 48khz 16bit PCM stream is 4 bytes.
1 frame of a 5.1 48khz 16bit PCM stream is 12 bytes.

A period is the number of frames in between each hardware interrupt. The poll() will return once a period.

The buffer is a ring buffer. The buffer size always has to be greater than one period size. Commonly this is 2*period size, but some hardware can do 8 periods per buffer. It is also possible for the buffer size to not be an integer multiple of the period size.

Now, if the hardware has been set to 48000Hz , 2 periods, of 1024 frames each, making a buffer size of 2048 frames. The hardware will interrupt 2 times per buffer. ALSA will endeavor to keep the buffer as full as possible. Once the first period of samples has been played, the third period of samples is transfered into the space the first one occupied while the second period of samples is being played. (normal ring buffer behaviour).

Edit to add: while playing a song

Code: Select all

$ cat /proc/asound/card1/pcm0p/sub0/hw_params 
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 1104
buffer_size: 4416

It sets the period size and buffer size, you might check on your system when you're playing local music and then youtube and see if there's any differences.

ETA2: tried with youtube (firefox) and this shows

Code: Select all

$ cat /proc/asound/card1/pcm0p/sub0/hw_params 
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 1104
buffer_size: 8832

so it looks like with local music the buffer size is 4 times, but with youtube it goes to 8 times.
And with 48000 you need to bump up the period size and associated buffer size.

this is a 48000 ogg file (local)

Code: Select all

$ cat /proc/asound/card1/pcm0p/sub0/hw_params 
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1200
buffer_size: 4800

ETA?: checked with using hdmi and this is what shows

Code: Select all

$ cat /proc/asound/card0/pcm3p/sub0/hw_params 
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1200
buffer_size: 4800

The access type changed, but not sure what that means (if anything)

I would suggest that you set your period size reasonable and set buffer size 8 times instead of 4 and see what that does.


PS: It makes my head hurt too *chuckle* I find it akin to voodoo in some respects.

[Anon-E-moose]

Rather than define a new dmixer why not use the default one

This should work (I think)

Code: Select all

pcm.!default {
        type plug
        slave.pcm "dmix:0.3"
}

Which only outputs 48000, which is what you want.

Edit to add: I wanted to have a volume control (alsamixer) for hdmi (only shows the spdif stuff) so I did this,
and it works, so I would expect what I posted above to work.

Code: Select all

pcm.softvol {
    type softvol
    slave {
        pcm "dmix:0,8"
    }
    control {
        name "soft"
	card 0
    }
}

pcm.svol {
    type plug
    slave { 
        pcm "softvol"
    }
}

ctl.svol {
    type hw
    card 0
}

[NeddySeagoon]

Anon-E-moose,

Thanks for keeping following up. Its not working quite as badly now. I have ...

Code: Select all

pcm.dmixer {
   type dmix
   ipc_key 1234
#   ipc_key_add_uid true # Needed ?
   ipc_perm 0666
   slave {
#      format S16_LE
      pcm "hw:0,3"

# speaker-test -Dhdmi:HDMI -c 2 uses
#Periods = 4
#was set period_size = 262144
#was set buffer_size = 1048576
# Works for local sources

                period_size 16384  #32768 #65536  #131072  # 262144 # not 1024
                buffer_size 131072 #131072 #262144  #524288  # 1048576 # not 4096

#                period_time 0
                rate 48000
   }
        bindings {
                0 0
                1 1
        }
}

# Whatever ctl magic thing
ctl.dmixer {
   type hw
   card 0
}

pcm.!default {
        type plug
        slave.pcm "dmixer"

Code: Select all

                period_size 16384  #32768 #65536  #131072  # 262144 # not 1024
                buffer_size 131072 #131072 #262144  #524288  # 1048576 # not 4096

need to be powers of two. SO I started with what speaker-test used, which worked for the wrong reasons and kept dividing by two until it appeared to work the the day but it horrible now.
My current guess, in that the IRQ at the end of a packet is not being serviced on in time. That's masked by a big buffer because it eventually catches up.
Its not short of CPU time as it has most of a 5950 to play with. One thing I can try is to test it when the CPU is busy, in case something is sleeping/power saving.

I'm still poking at it as the audio/video sync leaves a lot to be desired and intertube sources are really horrible.

[Anon-E-moose]

I wouldn't set either period or buffer size, they should auto-adjust, at least on my system they do, with both onboard and hdmi sound.

Just curious, what onboard sound and what hdmi card/audio ?


This is from different sources, letting alsa decide on period and buffer,
I've seen it go to 8 times on buffer to period, on another source

Code: Select all

$ cat /proc/asound/card1/pcm0p/sub0/hw_params            
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5504
buffer_size: 22016

$ cat /proc/asound/card1/pcm0p/sub0/hw_params            
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 12000
buffer_size: 48000

$ cat /proc/asound/card1/pcm0p/sub0/hw_params            
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 24000
buffer_size: 96000

[NeddySeagoon]

Anon-E-moose,
I don't have those knobs in /proc/asound/

Code: Select all

$ ls -R /proc/asound/ -l
/proc/asound/:
total 0
dr-xr-xr-x 10 root root 0 Dec 16 16:13 card0
dr-xr-xr-x  4 root root 0 Dec 17 13:47 card1
-r--r--r--  1 root root 0 Dec 31 13:50 cards
-r--r--r--  1 root root 0 Dec 13 13:18 devices
lrwxrwxrwx  1 root root 5 Dec 31 14:15 Generic -> card1
lrwxrwxrwx  1 root root 5 Dec 31 14:15 HDMI -> card0
-r--r--r--  1 root root 0 Dec 31 14:15 hwdep
-r--r--r--  1 root root 0 Dec 17 13:47 modules
dr-xr-xr-x  4 root root 0 Dec 31 14:15 oss
-r--r--r--  1 root root 0 Dec 31 14:15 pcm
dr-xr-xr-x  3 root root 0 Dec 31 14:15 seq
-r--r--r--  1 root root 0 Dec 31 14:15 timers
-r--r--r--  1 root root 0 Dec 17 13:47 version

/proc/asound/card0:
total 0
-r--r--r-- 1 root root 0 Dec 16 16:14 codec#0
-rw-r--r-- 1 root root 0 Dec 16 16:14 eld#0.0
-rw-r--r-- 1 root root 0 Dec 16 16:14 eld#0.1
-rw-r--r-- 1 root root 0 Dec 16 16:14 eld#0.2
-rw-r--r-- 1 root root 0 Dec 16 16:14 eld#0.3
-rw-r--r-- 1 root root 0 Dec 16 16:14 eld#0.4
-rw-r--r-- 1 root root 0 Dec 16 16:14 eld#0.5
-r--r--r-- 1 root root 0 Dec 16 16:14 id

/proc/asound/card1:
total 0
-r--r--r-- 1 root root 0 Dec 17 13:47 codec#0
-r--r--r-- 1 root root 0 Dec 17 13:49 id

/proc/asound/oss:
total 0
-r--r--r-- 1 root root 0 Dec 31 14:15 devices
-r--r--r-- 1 root root 0 Dec 31 14:15 sndstat

/proc/asound/seq:
total 0
-r--r--r-- 1 root root 0 Dec 31 14:15 drivers

am i missing a kernel option?

Code: Select all

$ lspci -nnk | grep -A3 Audio
0c:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 HDMI/DP Audio Controller [1002:ab28]
	Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Navi 21/23 HDMI/DP Audio Controller [1002:ab28]
	Kernel driver in use: snd_hda_intel
--
0e:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487]
	Subsystem: ASUSTeK Computer Inc. Device [1043:87c4]
	Kernel driver in use: snd_hda_intel

I want to use the first one with both 44.1kHz and 48kHz sample rate material.

-- edit --

Commenting out the period_size and buffer_size make it better on local material. Both sample rates and does not make web things any worse.
Overall, that's an improvement.

[Anon-E-moose]

SND_PROC_FS and associated verbose option ?


Both your audio interfaces should play both 44.1k and 48k

But if you make dmix be the default it will make everything output at 48k

here's what shows when I use hdmi, with softvol/dmix (not setting any sizes)

Code: Select all

$ cat /proc/asound/card0/pcm8p/sub0/hw_params 
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384

Edit to add: If you do aplay <options> <file> --dump-hw-params
what does it show?

[NeddySeagoon]

Anon-E-moose,

Code: Select all

$ grep SND_PROC_FS -A3 /usr/src/linux/.config
CONFIG_SND_PROC_FS=y
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
CONFIG_SND_CTL_FAST_LOOKUP=y

Thank you. I'm on 6.1.0-gentoo now and wasn't going to reboot until 6.2.0 was out.
It looks like I shouldn't wait that long.

[Anon-E-moose]

These are all the options I have set for sound (sorted)

CONFIG_SND=m
CONFIG_SND_ALOOP=m
CONFIG_SND_CTL_FAST_LOOKUP=y
CONFIG_SND_CTL_LED=m
CONFIG_SND_DMA_SGBUF=y
CONFIG_SND_DRIVERS=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_HDA=m
CONFIG_SND_HDA_CODEC_HDMI=m
CONFIG_SND_HDA_CODEC_REALTEK=m
CONFIG_SND_HDA_COMPONENT=y
CONFIG_SND_HDA_CORE=m
CONFIG_SND_HDA_GENERIC=m
CONFIG_SND_HDA_GENERIC_LEDS=y
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDA_PREALLOC_SIZE=0
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HRTIMER=m
CONFIG_SND_HWDEP=m
CONFIG_SND_INTEL_DSP_CONFIG=m
CONFIG_SND_INTEL_NHLT=y
CONFIG_SND_INTEL_SOUNDWIRE_ACPI=m
CONFIG_SND_JACK=y
CONFIG_SND_JACK_INPUT_DEV=y
CONFIG_SND_MAX_CARDS=32
CONFIG_SND_PCI=y
CONFIG_SND_PCM=m
CONFIG_SND_PCM_TIMER=y
CONFIG_SND_PROC_FS=y
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DEVICE=m
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_SND_SEQ_MIDI=m
CONFIG_SND_SEQ_MIDI_EVENT=m
CONFIG_SND_SEQ_VIRMIDI=m
CONFIG_SND_TIMER=m
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VIRMIDI=m
CONFIG_SND_VMASTER=y
CONFIG_SND_X86=y


The way I have my system set is use onboard (to stereo) with no dmix (only one stream at a time) but no changes to rate,
so I hear whatever rate the music is at, which I prefer, I notice when 44.1 gets sampled to 48 (slight but I notice)

If I set dmix on for the onboard, everything would play at 48k, no matter the card/audio device

Here's my whole .asoundrc

Code: Select all

pcm.!default {
    type plug
    slave {
        pcm "hw:1,0"
        rate "unchanged"
        channels "unchanged"
#       format "unchanged" 
    }
}

ctl.!default {
    type hw
    card 1
}

pcm.dp-out {
    type hw
    card 0
    device 8
}

pcm.softvol {
    type softvol
    slave {
        pcm "dmix:0,8"
    }
    control {
        name "soft"
	card 0
    }
}

pcm.svol {
    type plug
    slave { 
        pcm "softvol"
    }
}

ctl.svol {
    type hw
    card 0
}

It allows me to have the default be onboard audio with no changes to music
or hdmi with nothing (dp-out)
or hdmi with softvol/dmix (everything plays at 48k)

[Jimmy Jazz]

Team,

Here's the story. [...]
The mixing and sample rate conversion in operational but the result is broken up sound output, whatever the source material sample rate.

that's my config. Peraphs would it fit your needs,

I remember having some problemes with the capture...as my hdmi display cannot do input

Code: Select all

pcm.!dmixer  {
  type dmix
    ipc_key_add_uid false
    ipc_key 1024
    ipc_perm 0660
    ipc_gid audio
    max_periods 16 # The solution of stuttering
    slave {
      pcm "hw:CARD=HDMI,DEV=3"
     #pcm "hw:CARD=Generic"
        period_time 5000  # in us
        period_size 9216  #10240 #9216
        buffer_size 16384
        channels 2
#        format S16_LE
#        rate 96000 
    }
  bindings {
    0 0
    1 1
  }
  hint {
    show on
      description "Alsa HD mixer Output"
  }
}

pcm.!default {
  type asym # combined playback and capture
    playback.pcm {
      type plug # format conversion
        slave.pcm {
          type dmix
            ipc_key_add_uid false
            ipc_key 1024
            ipc_perm 0660
            ipc_gid audio
            max_periods 16 # The solution of stuttering
            slave {
              pcm "hw:CARD=HDMI,DEV=3"
             #pcm "hw:CARD=Generic"
                period_time 5000  # in us
                period_size 9216  #10240 #9216
                buffer_size 16384
                channels 6
#        format S16_LE
#        rate 96000 # caution: non compatible avec les flux de tailles differentes
            }
            bindings {
              0 0
              1 1
              2 0
              3 1
              4 0
              5 1
           }
        }
    }
  capture.pcm "input"
}

# input                                                                         
pcm.input {                                                                     
  type dsnoop                                                                   
    ipc_key 3129398                                                             
    ipc_key_add_uid false                                                       
    ipc_perm 0660                                                               
    slave.pcm "hw:CARD=Generic"                                                 
}                                                                               
                    

[NeddySeagoon]

Team,

Long time no update. Its still not fixed but I've noticed some bizzare behaviour which might give someone a clue.
Alsa is rock solid when the system is busy! Even with firefox.

Its a 32 thread AMD 5950x with 128G RAM. I don't plan any upgrades.
For updates I run MAKEOPTS="-j32" and portage jobs=3. Seeing a load average over 100 is not unknown.

Heres the bizzare behaviour ... when the load average is over 40, alsa is happy.

[dbtx]

NB: I'm somewhat out of my depth, even if only for sticking to gentoo-sources-5.10.x. There are some things not yet mentioned here that traditionally could make JACK work with ALSA more nicely, or less. So this is sort of a shotgun approach. Have you tried sys-process/rtirq to play with priorities of kernel tasks like snd, rtc, timer? Are you using CONFIG_PREEMPT(_*) ? Are you using CONFIG_NO_HZ(_*) or CONFIG_HZ_PERIODIC? IIUC, the latter is best for low-latency audio, or it was, back when I was still climbing to this ledge. Those options might not exist or have same names in linux-6.x

But it seems like a case of moderate load average keeping CPU cores awake and always handling interrupts. Are you using CONFIG_CPU_FREQ / dynamic clocking, or maybe "Cool'n'Quiet" or the like within UEFI ? I remember having awful audio performance with Yoshimi in Raspbian on a Pi3B+ when I left the cpufreq scaling_governor at the default ondemand or conservative or whichever, but the synth worked well with far more reasonable polyphony after I set the governor to performance, i.e. just keep the cores at full speed all the time. I think you can set different governors for different cores but I'm not sure if it's so easy to set the thread affinity for kernel tasks to any core and 'pin' the ALSA bits to a less-sleepy one. Maybe the scheduler is sma^Wlucid enough to keep such tasks on cores that are already and/or always lively. I don't know.

Another thing that came to mind was cgroups' auto-scheduling-tuning-powers but I never seemed to need to actually learn about that, so I never did. :shrug:

[Anon-E-moose]

What does the latest .asoundrc look like?

The best sound (on my system using straight alsa) was not to set any period/buffer and let it auto size them.

But in playing with pipewire/wireplumber it seems that setting either the period or buffer size too large actually causes more xruns.
The way I have it tuned now (not perfect) I hear a stutter once every 2 or 3 albums worth of songs, typically last less than 1/2 second.

And alsa/etc playback does seem to change between no or low load and higher cpu load.

If you are going to try and set period/buffer, I would start low and increase it in moderate amounts till you achieve what you want.

https://www.alsa-project.org/wiki/FramesPeriods

[Anon-E-moose]

I've noticed something with alsa, with 6.1.7, I would get an occasional stutter (once every few hours, sometimes just once a day) for 1 or 2 seconds,
but with moving to 6.1.22, I'm not seeing any stutter.

[krumpf]

After tinkering (a lot) with my asoundrc, here's what I get from alsa.
A lot of default values are defined in alsa files, in your case, I suggest reading :
/usr/share/alsa/alsa.conf
/usr/share/alsa/cards/HDA-Intel.conf
/usr/share/alsa/pcm/dmix

Maybe you should try this .asoundrc, forcing alsa to use its default from /usr/share/alsa/cards/HDA-Intel.conf, just changing the options you need.

Code: Select all

# asoundrc
defaults.pcm.card 0
defaults.pcm.device 3 # both lines equivalent to pcm "hw:0,3"

defaults.pcm.dmix.format S16_LE 
#defaults.pcm.dmix.rate 48000 # 48KHz is dmix default
#defaults.pcm.dmix.channels 2 # 2 is dmix default

defaults.dmix.YourCardName.period_size 1024 # 1024 is dmix default
defaults.dmix.YourCardName.periods 4 # 16 is dmix default

NOTE : replace YourCardName by its name in aplay -l (ex. I own a XonarD2X, alsa names it D2, so for me option would be defaults.dmix.D2.periods).

The period_size and buffer_size are defined in frames, not in bytes. Afaik, the "power of 2 rule" is only useful for OSS compatibility.
The period_time and buffer_time are expressed in microseconds. You don't need to define size and time, only 1 value is needed.
E.g. when playing a 48000 Hz sound, if you set period_size 4800, it will generate a hardware interrupt every 100 millisec (or 100000 µs), equivalent to period_time 100000
Small period size means less latency, but more hardware interrupts. (Important for gamers, don't flood your CPU with sound interrupts)

Also, buffer_size = period_size * number of periods; so you either set the buffer_size, or the number of periods.
It seems the alsa devs choose to set only the period time and number values, and let the buffer auto-adjust.

Another suggestion I'd like to make is for you to check /etc/modprobe.d/alsa.conf,
see if you get an option that sets your HDMI output as index 0 (options snd slots=snd-hda-intel),
or maybe disable your motherboard soundchip ?

Maybe all this can give you some hints. (and I hope I didn't write anything wrong or stupid )

[NeddySeagoon]

Team,

I've had no sound at all since my last kernel update, at 6.2.1 but that might be considered an improvement :)
Anyway I have been running

Code: Select all

echo check >/sys/class/block/md127/md/sync_action

today. Its 4x8TB drives in raid5. My /home is there, so its a bit sluggish.
That's a good time to poke the bear that is called alsa,

I traced the no sound at all to the hardware driver changing

Code: Select all

 #      pcm "hw:0,3"
      pcm "hw:0,10"

now its as bad as ever.

Code: Select all

speaker-test -D hdmi:DEV=4 -c 2

works.

Code: Select all

speaker-test

which does the same thing but depends on /etc/asound.conf to discover hdmi:DEV=4, does not.
That also adds in dmix ...

In fact

Code: Select all

aplay  hdmi:DEV=4 -c 2 <Any 48k sample rate .wav>

seems to work.
As soon as /etc/asound.conf is added, as follows, it all falls to bits.

Code: Select all

pcm.dmixer {
   type dmix
   ipc_key 1234
#   ipc_key_add_uid true # Needed ?
   ipc_perm 0666
   slave {
#      format S16_LE
#      pcm "hw:0,3"
      pcm "hw:0,10"

# aplay says
#  buffer_size  24064
#  period_size  6016
#  period_time  125333

# speaker-test -Dhdmi:HDMI -c 2 uses
#Periods = 4
#was set period_size = 262144
#was set buffer_size = 1048576
# Works for local sources

#                period_size 16384  #32768 #65536  #131072  # 262144 # not 1024
#                buffer_size 131072 #131072 #262144  #524288  # 1048576 # not 4096

#                period_time 0
                rate 48000
   }
    	bindings {
                0 0
                1 1
        }
}

# Whatever ctl magic thing
ctl.dmixer {
   type hw
   card 0
}

pcm.!default {
	type plug
        slave.pcm "dmixer"
}

so the problem is caused by something there as playing 48kHz same pate material direct to the device works.

Time for a binary search :)

-- edit --

After some slash and burn, I'm left with

Code: Select all

pcm.!default {
	type plug
        slave {
                pcm "hw:0,10"
                rate 48000
        }
}

Which works for 44.1kHz and 48kHz sample rate material.
... but no dmix, which is required to avoid the 2+ sec of audio getting chopped of the start of every track as the streams is opened.

[Anon-E-moose]

Why are you making a type dmix, instead of using the dmix.conf? Does the default dmix not work (or work well)?

does something like this not work

Code: Select all

pcm.!default {
    type plug
    slave {
        pcm "dmix:0,8"
    }
}

Set dmix addr properly for your system