no audio on T410 (8086/3b56) - mixer not used (DMA/IRQ problem?)

[ttcoder]

I have a T410 with no audio at all from the HDA driver.

Controller:

device Multimedia controller (Audio device) [4|3|0]
	  vendor 8086: Intel Corporation
	  device 3b56: 5 Series/3400 Series Chipset High Definition Audio

Digging in the syslog, I find

	0x17aa  subsystem_vendor_id
	0x215e  subsystem_id

(seems to be called HDA_CODEC_CX20585 in the FreeBSD sources)

Codecs:

KERN: hda: Codec 0 Vendor: 14f1 Product: 5069, Revision: 1.0.3.2 Quirks: 0700
		=> the actual "audio" codec: Conexant / HDA_CODEC_CX20585
	KERN: hda: Codec 3 Vendor: 8086 Product: 2804, Revision: 1.0.0.0 Quirks: 0700
		(=> aka HDA_CODEC_INTELIP2 / "Intel Ibex Peak", seems to be un-used or for digital/HDMI stuff)

More coming up...

[ttcoder]

Situational awareness:

• seems #6049 is for a similar chipset (or maybe it's the exact same, and the title line has a typo?). Though the widget listing is *very* different from mine, so cannot use that data to debug my situation it seems. Possibly because the machine in that ticket has 2 different soundcards, whereas there's only one HDA device here.

• ticket #14242 has a somewhat different chipset, but the widget listing is very much the *same* as here, so maybe fixing that ticket would fix this ticket, and vice-versa?

• the FreeBSD 11 driver over at ​http://xref.plausible.coop/source/xref/freebsd-11-stable/sys/dev/sound/pci/hda/ has a couple differences compared to Haiku's; not sure if those differences account for the lack of audio in our driver.

See FreeBSD's hdaa_patches.c, look for Conexant / HDA_CODEC_CX20585:

​http://xref.plausible.coop/source/xref/freebsd-11-stable/sys/dev/sound/pci/hda/hdaa_patches.c#656

Not sure how to translate that paragraph of code to haiku code..

[ttcoder]

Symptoms:

• the driver builds an output tree without a mixer, according to the syslog
• as soon as I open MediaPlayer with a song, media_addon_server crashes (thread AudioMixerControl: BBufferCache::GetBuffer(): IDs mismatch)
• syslog goes,

  KERN: hda: buffer_exchange: Error waiting for playback buffer to finish (Interrupted system call)!
  KERN: hda_stream_stop()
  

• media preferences are messed up: they look exactly the same as in https://dev.haiku-os.org/attachment/ticket/14242/broken_hda_x220.png

(which has 8086/1c20 (17aa/21da))

Only difference is the items tree on the left -- mine also includes a "firewire 0" item, but seems irrelevant to HDA.

Questions:

• the syslog mentions that the "Speaker" widget's inputs can only possibly be 16 and 17:

  KERN: hda: 31: Pin complex
  KERN: hda: 	[Output]
  KERN: hda: 	Fixed, Speaker, Other analog, N/A, Association:15
  KERN: hda: 	Supported power states: D0 D1 D2 D3 
  KERN: hda: 	[Power] [Conn. list] [Stereo] 
  KERN: hda: 	Inputs: 16 17 
  

  Widgets 16 and 17 are "Audio Output" widgets. The Audio Mixer (widget 36) is not listed. So it means we cannot possibly implement a solution that connects the Speakers to the "Mixer" widget, correct?
• if so, will the Media Preferences be able to cope with it, display controls and so on ?
• I suppose the drivers on other platforms (BSD..) deal with that, find a way around that ?

What I've tried so far:

Downloaded the latest source from git to try various hacks (as I had done some years ago on my R61, see #8270).

1) In the FreeBSD driver, this chipset is listed as "0 quirks":

hdac.c:

		{ HDA_INTEL_PCH,     "Intel Ibex Peak",	0, 0 },

So I've remed out the 'quirk' in the haiku driver.

Result: syslog: no change in DMA snooping, I still get KERN: hda: DMA snooping: no

Result: audio: I still get a media_addon_server crash, though it takes ~30 seconds now. Still no audio output, nor media settings. Though I no longer get this though, on hot restart:

		buffer_exchange: Error waiting for playback buffer to finish (Interrupted system call)!

Anyway this seems to have little impact.

2) Tried to unplug the PSU; a beep is emmited indeed, but no change in media_server audio (as per the comment in #4755 : "On some machines, a system beep is emitted by the BIOS when plugging/unplugging the power supply. Doing so initializes the codec, and then sound starts working in Haiku.").

[ttcoder]

I think I've found out why the settings look like this:

The code looks like this:

static void
hda_create_control_for_complex(hda_multi* multi, uint32* index, uint32 parent,
	hda_widget& widget, bool& gain, bool& mute)
{
  ...
	if ((widget.flags & WIDGET_FLAG_WIDGET_PATH) != 0)
		return;

	hda_create_channel_control(multi, index, parent, 0,
		widget, false, widget.capabilities.output_amplifier, 0, gain, mute);
  ...
      if(..)
    {
		// Recurse:
		hda_create_control_for_complex(multi, index, parent, child, gain, mute);
    }

Note that in this case, all 3 columns (right HP, HP, Speaker) refer to the same widget # 16 (Audio Output). So the first column succeeds in calling hda_create_channel_control(). But when the "Headphones" and "Speaker" columns attempt to call it, those calls bail out as the WIDGET_FLAG_WIDGET_PATH flag is already set on widget 16!

I wonder how it works in the general case.. Maybe other chipsets provide a different Audio-Out for each pin complex ? @korli any idea?

[ttcoder]

After tidux's contribution in #14242 (thanks!) I went looking for the linux source to cross-check where the (short) dmesg lines come from:

​https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda

But I ended up looking at the change-log history instead.. And found commits titled

• ​ALSA: hda - Add initial support for Thinkpad T410s HDA codec
• ALSA: hda - Move Thinkpad X220 to use auto parser ("add the TP410 fixup instead.")

I was confused at first because the linux drivers refers to chip "cxt5066"; but digging in the source I see reference to my hardware's IDs:

SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo Thinkpad", CXT5066_THINKPAD),
...
+	{ .id = 0x14f15069, .name = "CX20585",
+	  .patch = patch_cxt5066 },

So it seems that patch could help me (and tidux)! How to apply it to the Haiku source though hmm

Much of that change-set is for fixing Mic-In ..etc; but parts of it refer to my infamous Speaker/31 (0x1f), for instance:

+	/* Port G: internal speakers  */
+	{0x1f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT},
+	{0x1f, AC_VERB_SET_CONNECT_SEL, 0x00}, /* DAC1 */
+

[ttcoder]

I tried to do the equivalent of AC_VERB_SET_CONNECT_SEL by sending this

				if( widget.node_id == 31 )
				{
					uint32 mux = 0;
					uint32 verb = MAKE_VERB(
						audioGroup->codec->addr,
						widget.node_id,
						VID_SET_CONNECTION_SELECT,
						mux
						);
					if (hda_send_verbs(audioGroup->codec, &verb, NULL, 1) != B_OK) ......

But no joy.

Also tried playing with the "send verbs: 16..." part but no luck either.

I should probably look at ​https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/patch_conexant.c as a whole, rather than just the change-set excerpts.

[korli]

The comment from #14242 also applies here: https://dev.haiku-os.org/ticket/14242#comment:9

[ttcoder]

Thanks korli

So the changes over at ​https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_conexant.c#L712 ended up being "Pin Config" uint32 values, so I applied them in hda_codec_parse_audio_group() [*]

The resulting syslog shows the pin-config being tweaked indeed, seems to be the result intended by the linux driver:

KERN: hda: 25: Pin complex
KERN: hda: 	[Output]
KERN: hda: Pinconfig T- for 25 is 0x042110f0 ====
KERN: hda: Pinconfig T+ for 25 is 0x042140ff
KERN: hda: 	Jack, Right HP out, 1/8", Green, Association:15

The tweaks seems to be for something minor (the jack "color" changes from black to green) and something possibly important : association (what's that??) changes from 0 to F.

I moved my uint16 "verb" inits to where you recommended. Tried with and without them. See diff and syslog attachments below.

As to the ​ACPI stuff, I stumbled on this line

led_set_func = symbol_request(tpacpi_led_set);

It seems to be the important one, to perform the TPACPI_LED_MUTE call later down the function. But the symbol tpacpi_led_set is nowhere in the linux hda driver?

You'll see in the syslog that the patched pin configs produce "Association:15", but it seems that is unchanged; i.e. the unpatched haiku driver was also saying the same thing; I'll try to investigate, find out what an "association" is, and why the 0xF patch makes it "assoc: 15" (seems normal) and the unpatched driver with value 0x0 also says "assoc: 15".

Overall, I tried a few combinations with no luck yet; will dig a bit more (or I'll ask tidux for more logging, should be easier :-)

[*] details:

the linux driver's fix is applied in
	apply_fixup() (hda_auto_parser.c:824) ; it's of type HDA_FIXUP_PINS, which means calling =>
	snd_hda_apply_pincfgs() => calls..
	snd_hda_codec_set_pincfg() (in hda_codec.c) =>
	snd_hda_add_pincfg()

[ttcoder]

with extra tracing showing the linux-like Pin Config tweaks ..etc

[ttcoder]

modified hda_codec.cpp as advised, added tracing

[korli]

the code should look like:

audioGroup->widgets[0x19-0x10].d.pin.config = 0x042110ff;
audioGroup->widgets[0x1a-0x10].d.pin.config = 0x21a190f0;
audioGroup->widgets[0x1c-0x10].d.pin.config = 0x212140ff;

I don't really understand what this is supposed to fix (in Linux it helps the parser to find the correct primary output). The audio output 16 is already found and connected with the pin outputs 25 and 31. The hda driver currently doesn't really use the sequences for anything.

[ttcoder]

Reviewed more code and I'm now convinced those 3 patches for "pin complexes" are not related to the bug: they just fix usage of docking stations (thinkpad docks), not the internal speakers and headphones.

Today I've worked on tidux's latest data (ticket:14242#comment:13)

I think the verb of interest in his data is

0x01024011

Which decodes to VID_SET_CONVERTER_FORMAT, 16 bit, 44 KHz.

Both are different from what I had here!

It seems the sample rate is affected from Media (prefs), to the driver. So I've changed the setting to 44 KHz, restarted media, but no change.

My syslog (with extra tracing) looks closer to linux now though:

KERN: hda: stream: 1 fifo size: 255 num_io_widgets: 1
KERN: hda: widgets:
KERN:   hda-verb       <0x1024031>:  [0] nid 0x10 (16): pload 0x4031   vid 0x20000 (VID_SET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x1070610>:  [0] nid 0x10 (16): pload 0x10   vid 0x70600 (VID_SET_CONVERTER_STREAM_CHANNEL)

For the sample rate, it seems to be the other way around (IIUC the code): the driver retrieves the sample rate from the hardware, and passes it on to haiku Media. So that one seems more suspicious: why does the linux driver detect 16-bit samples from the hardware, whereas Haiku detects 24-bit samples, hmm. I'll try to just hardcode 16-bit in haiku, see if it flies.

I have more things to try, will post a short summary in tidux's ticket when done.

[ttcoder]

Got the full verb dump from #14242, modified my hda driver to send the ones directed to codec 1 "en masse". Still no sound.

To do:

• cold boot ?
• try to send en masse to codec 3 too, in case there is a hidden connection to codec 1 ?
• maybe the X220 differs enough from T410 that a full dump is not the way to go, and I should look for ideas line by line instead ?
• post my hda_dump() ..etc code here in case someone wants to pick up?
• maybe the hardware is deffective? get nova going to confirm/infirm hypothesis -- EDIT: audio works great with OpenBSD5.7 5.9/genode/nova, so the problem is somewhere in Haiku indeed.

[waddlesplash]

Seeing how many chipsets from many different vendors don't work, my guess at this point is that we are missing some common setup step rather than some magic set of verbs. Because often these devices have working audio input, it's just output that's broken, yes? So the "mixer not insertable in output path" may be the actual problem, so to speak, rather than a symptom of another one.

[ttcoder]

Update (more coming):

• could not send anything to codec3; controller->codecs[3] is NULL; turns out it's because the driver fails to initialize that one; probably makes sense since it's an HDMI(?) codec; still would have liked to experiment with it "just in case", oh well.
• did something of a line-by-line comparison; seems the haiku driver is sending the same verbs as linux (on codec 0 anyway) in a slightly different order; including the oft-quotted VID_SET_EAPDBTL_EN (external amplifier).
• also copied the modified driver to another machine, known to work (sanity check to make sure I wasn't mindlessly trying to make the driver work after unknowingly breaking something else in it) : I get audio, and extended tracing, it all checks out.

I'm not giving up yet... But it will be a few months before I tackle this again. I have 2 other OS'es I'm thinking of trying, to check the "warm boot from other OS" effect/theory.

[ttcoder]

some tracing code I wrote that might be of use to others

[ttcoder]

Posted a zip with stuff for working on this ticket and the peer ticket's log, in case somebody else feels wildly motivated:

• a small tool to translate the 0x123.. verb hex values into human readable strings
• function for sending the same verbs that linux does, in the haiku driver
• some grep/cut/sed helpers
• tidux's raw linux log from peer #14242
• that same log again, but decoded with the above tool

@waddlesplash maybe I should check again in the logs, but I think the linux driver (as evidenced by its log) does not attempt to use the mixer either; it follows the hints given by the hardware, which claims that the mixer cannot be used for output. Seems legit (there are other HDA chipsets doing the same). Maybe I should update this ticket's title.

Agree it might be a more 'fundamental' bug in the driver, not just a matter of sending magic verbs.

Hmmm.. Just had a couple ideas..

• I should send verbs to codec3 just _before_ the call to hda_codec_delete() is made (right before it aborts creation of it and NULLs it out at the end of hda_codec_new())
• and while I'm at it, also saw this in the OpenBSD driver; no idea if it applies: "OpenBSD: azalia.c:514: "disable MSI, use INTx instead /* if sc->pciid == PCI_VENDOR_INTEL */"
• and if tidux's setup for building the driver, he could try my 'diff', in case his X220 behaves differently / does not behave as closely to my T410 as the various sources make it to be.

[ttcoder]

Wow. Sound works today.

Was working with qemu on an "audio_out" scenario. At about an uptime of 2+ hours, on a whim I launched MediaPlayer and boom -- the music plays!

That's with Haiku x64 R1/beta1, using the "stock" HDA driver. The (acpi-driven?) "mute" button works for muting and un-muting audio. The "-" and "+" keyboard keys do not do anything, however. Didn't try headphones yet.

Did the qemu run manage to initialize the HDA hardware ? Or did the hardware preserve its state from yesterday's test of the OpenBSD driver ? This computer remained powered off for 10 hours in between. So if it's the latter, just wow. Or was it just a matter of having a 2 hours uptime before trying ? (saw things like that before with media_server, but more on a scale of minutes, not hours). Will test more over the next few days and update.

Syslog differences follow..

• Difference in irq vector:

  	KERN: hda: enabling PCI bus mastering
  	KERN: allocate_io_interrupt_vectors: allocated 1 vectors starting from 20
  	KERN: msi_allocate_vectors: allocated 1 vectors starting from 20
  	KERN: msi enabled: 0x0081
  	KERN: hda: using MSI vector 20
  

whereas in https://dev.haiku-os.org/attachment/ticket/14581/syslog_with_additional_tracing.txt you'll see it using 19

• DMA snooping differs:

KERN: hda: DMA snooping: yes

whereas here https://dev.haiku-os.org/attachment/ticket/14581/syslog_with_additional_tracing.txt it says

KERN: hda: DMA snooping: no

• settings:

3 extra lines after "looking for settings file" on this side: https://dev.haiku-os.org/attachment/ticket/14581/syslog_with_additional_tracing.txt

• lots of "MTRR" differences (is MTRR related to DMA ?)
• no change in the rest (routing from widget to widget, logged init verbs..)
• couldn't compare setmix()-style logging, as that logging is not activated in the "stock" driver.

If I understood irq and dma I could review the OpenBSD 5.7 5.9 code to see if it does something special with that.. But that's probably above my pay grade.

EDIT: to clarify the chronology, the syslog differences above occured, obviously, at boot-up time; i.e. already at boot-up time, Haiku decided to use DMA snooping ..etc (whatever that is). Then I did some qemu fiddling for 2 hours. Then I launched MediaPlayer, and got audio output. Anyway will try different cold boot combinations each morning when I switch this computer on.

Further EDITS, which make it look like (at the very least) the original HDA related bug is compounded by media_server bugs:

• day 2: cold boot R1/b1 x64; launch MediaPlayer after uptime of 50 s. => no audio
• day 2, checked again after 1h40 uptime: audio works! (nice easter egg in the Haiku About Box when left open BTW)
• day 3:
• --> 32-bit, tweaked driver: no audio even after a fairly long time
• --> R1/b1 x64: works again after e.g. 1h40; there we go
• day 4:
• --> x64: works after 9 minutes (accidentally clicked a youtube vid early after logging; MP works too)
• day 5:
• --> 3 minutes..

EDIT: see related ticket:12356#comment:10 for some "test harness" code that bypasses media_server, calling B_MULTI_BUFFER_EXCHANGE directly, avoiding all the buffer sillyness.

[waddlesplash]

Difference in irq vector:

This isn't relevant; MSI interrupt vectors don't really have any numerical meaning besides initialization order.

DMA snooping differs:

This is a huge difference. The driver is supposed to enable or disable this based on your device ID; it shouldn't be different across reboots with the same driver!

lots of "MTRR" differences (is MTRR related to DMA ?)

It is; this is probably explained by "DMA snooping: yes" (all MTRR changes are done by the driver.)

day 2: cold boot R1/b1 x64; launch MediaPlayer after uptime of 50 s. => no audio day 2, checked again after 1h40 uptime: audio works! (nice easter egg in the Haiku About Box when left open BTW)

Wow, that's ... really, really weird. I guess I should test with my laptop to see if the same is true here. I wonder what could be going on in the HDA driver to cause this?

[ttcoder]

DMA snooping differs:

This is a huge difference. The driver is supposed to enable or disable this based on your device ID; it shouldn't be different across reboots with the same driver!

Well yet here we are... The archived syslog was captured when I started working on this ticket with gcc2-32bit, it should be a reliable data point. As to the snooping=yes part, I now get it at every single boot of x64 (tried again once more after the two edits above), so pretty darn reliable too. I'll try booting in 32-bit haiku today to check.

EDIT: I'm now booted into my old 50465 x32, the syslogs have the 3 previous boot-ups preserved, plus the current one, and all 4 have the KERN: hda: DMA snooping: yes line. So I'm not sure how I could have captured a syslog three months ago with a "no".. Anyway it might just be a red herring. I'll see how much uptime, if any, is needed for sound to "activate" here in x32-bit.

day 2: cold boot R1/b1 x64; launch MediaPlayer after uptime of 50 s. => no audio day 2, checked again after 1h40 uptime: audio works! (nice easter egg in the Haiku About Box when left open BTW)

Wow, that's ... really, really weird. I guess I should test with my laptop to see if the same is true here. I wonder what could be going on in the HDA driver to cause this?

Actually, not at all -- by which I mean it's consistent with past experience, not that it's a desirable behavior ;-). Ever since I started using Haiku (is that 6 years?) I've had problems with media_server remaining silent for the first few minutes, on most machines I've ever used. Dane also had me add a "5 seconds delay after commandcenter autostart" some time back, so as to not disturb media_server after a reboot or it'd remain silent. First time I see this phenomenon last for 40 minutes or some such though (still didn't finish "bracketing" the delay yet). I always pinned it on media_server rather than HDA, what with the complex BBuffer code and all. Could be wrong.

I believe the most logical course of action at this point is...

• close this ticket as not-reproducible, since my laptop got "unbricked" in some mysterious and unfathomable way, so there's no more HDA driver work that's possible on it at this point; maybe someone who wants to work on the peer X220 ticket can pick up where I left with my zip-of-goodness above.. Or tidux can run the OpenBSD driver on his X220 in case it has the same 'magical' effect it had on my laptop :-).. If my laptop ever gets "bricked" (probably too strong a word) again I would re-open this. Maybe I should try to not only power it off but also unplug it from mains and remove the battery..
• gather more data about that "media_server silent for minutes after boot up" bug that's been there for some time. (EDIT: see #7284 for support data)

EDIT: @waddlesplash: posting a reduced version of my answer here, since the effing trac won't let me post a new post (complains about "spam", then inflicts me 13 slow-as-molasses captchas, and finally Web+ CRASHED):

Yes it seems that VID_SET_PIN_WIDGET_CONTROL is a critical part of the equation; however with a quick look at the zip-o-goodness I see I had already looked into that one, and found it to be equivalent in payload to the one of the linux driver:

		0x01f70740,		0x01f70100,
						// VID_SET_PIN_WIDGET_CONTROL ============== same as haiku..
						//hda:   hda-verb       <0x01f70740>:  [0] nid 0x1f (31) :  vid 0x707 (VID_SET_PIN_WIDGET_CONTROL)   pload 0x40

I'm not giving up on this ticket, given the now familiar pattern of this laptop "forgetting" about the working state after ca. 15 hours of being powered off and needing a new "inoculation" of OpenBSD to have working audio again, however a bazillion things need to be attended to in priority, so not sure when i'll return to this

[waddlesplash]

I don't think it's a media_server issue at all; running in VMware or VirtualBox with a virtual HDA device, there is sound immediately after booting.

Trying to change certain HDA settings in Media preferences winds up with "General system error", at least for me, though I didn't wait 2 hours yet to see if it starts working after that. Something is still definitely broken.

[waddlesplash]

I just ran into this: ​http://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/drivers/audio/hda/hda_codec.cpp#1350

Perhaps that's relevant?

[tidux]

This is definitely an initialization problem. Warm boot from Linux or OpenBSD results in flawless sound, cold boot results in mismapped input and output channels and no sound.

[tidux]

I'm starting to suspect the one output and three input channels are mapped completely backwards - they should be one input and three output. The laptop clearly only has one input channel.

[pulkomandy]

Removing HDA audio tickets from Beta2 milestone, no one has worked on it and opensound is available at least as a stopgap.

[cocobean]

Confirmed this sound device, Intel 3400-based chipset, works on R1B2 x86 (hrev54154+123) - both audio out and headphone out jacks tested.

[modeenf]

On my Intel 3400 based system it dosen't work (Lenovo x201).. x86_64, hrev54957. Not even Open Sound.

The Media Addon has Right Headsphones that one can change. Left Headsphones and two speakers ar all blank.

[modeenf]

As a reference we have ​https://cgit.freebsd.org/src/tree/sys/dev/sound/pci/hda

Bu I also found out that HelenOS has it's own implementation, A smaller one and newer implementation. ​https://github.com/HelenOS/helenos/tree/master/uspace/drv/audio/hdaudio

Looking att some othe codec.h file I notised that

​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/audio/hda/hda_codec_defs.h, line 126 #define VID_SET_STRIPE_CONTROL 0x72000 Chould be #define VID_SET_STRIPE_CONTROL 0x72400

This did nothing for my bug, thoug.

For me our HDA code are realy complicated to follow. HelenaOS was some what easier but then it waqs not that big.

[waddlesplash]

Please retest on a recent nightly; korli's changes to HDA init a few months back fixed HDA from cold boot on my hardware at least.

[ttcoder]

Well, seems the changes were related to my chipset even if they didn't seem to be to my untrained eyes : I dd'ed hrev56158 to a USB stick, cold booted into it, and audio works!

Looks like this can be closed. I'm looking forward to installing beta4 when it's out, then I will no longer have to warm-reboot that particular thinkpad from Genode or Haiku-on-Genode in order to get audio output

[waddlesplash]

Very good.

[bellekaseh]

Hi - I'm running up-to-date 64-bit beta4 (Haiku shredder 1 hrev56578+69 Feb 11 2023 07:25: BePC x86 Haiku) on a 4th-gen Intel i5 Thinkpad T410 with the "Intel Corporation 5 Series/3400 Series Chipset High Definition Audio". The machine came with a fresh install of Windows 10, which I nuked, in order to install Haiku on the SSD.

In Haiku, the audio exhibited the behaviour described here; media would appear to play in MediaPlayer (counter incremented, VU meters danced), but no sound emerged.

The warm boot remedy from another OS (MX Linux, in which I played some media, then tweaked the audio volume using the hardware keys) worked. Let's see if the initialisation sticks!