From nobody Tue Apr 08 16:21:55 2025 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXBDX24P9z5scYN for ; Tue, 08 Apr 2025 16:22:04 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXBDW5MmYz3w0M; Tue, 08 Apr 2025 16:22:03 +0000 (UTC) (envelope-from jakob@alvermark.net) Authentication-Results: mx1.freebsd.org; none Received: from c-92-35-77-188.bbcust.telenor.se ([92.35.77.188] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.1 (FreeBSD)) (envelope-from ) id 1u2Bi0-00000000FX5-1hlj; Tue, 08 Apr 2025 18:21:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7HlcwK1s5bhppU2aa3MirgIeye8pETnYGv3fFkniVSY=; b=LobDdwUW/XNVvamzx9LeOOms32 ZKBU9jWapvYpzeU7zsZoZT74gUB21UJ5bu2Yv+LBWPZL5fGOjQpIgMbCqI3JMMY/bV1sZ1JsJTeTB UkDNZvBawYykEoqsFsBnJfqDGRQFGejCNxQT2pN1eNsn6cEL2z1EmOVi+xW1zkavm1pI09H6u0UFA 9CTXI5cJkoBtcBqC6ENabL21I2GCDM7CXBlC8/6N2EvmKFsQghM4qmi09FgeFTihXt9QJJuBxYZYm 5V/N+FohB153ThP4SgymTd6kqLrSNEzUdnp2PfD+IQCn9v9yd16NvUf7+Ns+kyQ36Pi5lro4pUxR/ jAfQTIfA==; Received: from wggw.ownit.se ([84.55.106.55] helo=[192.168.22.4]) by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1u2Bhz-000HXB-U2; Tue, 08 Apr 2025 18:21:55 +0200 Message-ID: <7f21cd55-5bb7-470f-88ae-c259710460bb@alvermark.net> Date: Tue, 8 Apr 2025 18:21:55 +0200 List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Call for testing] sound: Implement /dev/dsp as a router device To: Christos Margiolis Cc: freebsd-multimedia@freebsd.org References: Content-Language: en-US From: Jakob Alvermark In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34971, ipnet:185.34.136.0/24, country:IT] X-Rspamd-Queue-Id: 4ZXBDW5MmYz3w0M X-Spamd-Bar: ---- On 2025-04-08 00:23, Christos Margiolis wrote: > Hello Jakob, > > Jakob Alvermark wrote: >> Hi, >> >> >> This is cool. >> >> I did some quick testing. >> >> Playing some audio and plugging in my USB-C headset the audio switches over >> to the headset and continues playing in the headset. >> >> However, unplugging the headset does not seem to work fully. If I play >> something in chromium (a Youtube video for example), it stops. > See what I write below, it could be a similar issue. Also, does this > happen on other browsers, say, firefox? Interestingly, with firefox, the audio does not switch over to the headset. I tried this: - Start playing audio in firefox and start playing some audio in chromium. - Plug in USB-C headphones. - The audio from firefox still plays through the laptop speaker, but the chromium audio switches over to the headphones. - Unplug headphones. - Firefox audio still plays through laptop speakers as if nothing happened, chromium audio stops. >> I tried playing an mp3 file using audio/mpg123, and when unplugging the >> headset I get this error: >> >> [src/libout123/libout123.c:out123_play():746] error: Error in writing audio, >> wrote only -1 of 2304 (Invalid argument?)! >> main: [src/mpg123.c:play_frame():857] error: Deep trouble! Cannot flush to >> my output anymore! > I am not familiar with audio/mpg123, but the error message suggests that > the program exits upon a write() error. That is not really an issue of > sound(4), but that audio/mpg123 exits on the first write() error. mpv > for example, or mplayer as you said, do not have this problem. > > My first guess would be that the error is generated during the > hot-unpluging, because in the time window between the device detach and > the switch to the new default device, write() will have failed since the > device stopped doing IO at this point. That is not wrong behavior on > sound(4)'s side though. > >> On the other hand, multimedia/mplayer does work, switching seamlessly >> between the laptop speaker and headset. > Just to make sure, the switching is successful even during IO, right? Yes, with mplayer, switching works fine, both plugging and unplugging, while playing an mp3 file. >> Jakob >> >> On 2025-04-06 21:08, Christos Margiolis wrote: >>> I've been working on a patch [1] to re-implement /dev/dsp as a >>> router/virtual device. The commit message in the review explains all the >>> high-level details and reasons behind the patch. This is the first of a >>> series of patches I'm working on. >>> >>> For regular users, the main functional difference is that with this >>> patch, /dev/dsp is an actual router device (like when using >>> virtual_oss), which means that we have hot-swapping (i.e., changing the >>> default device and routing audio to it during IO without needing to >>> close and re-open /dev/dsp) built into sound(4). >>> >>> Feel free to test the patch and please let me know if there's anything >>> that breaks or could be improved. You can play around with it just by >>> recording/playing audio as you always do, try some hot-swaps, >>> hot-(un)plugs, and anything that can stress test it. Just make sure you >>> open /dev/dsp, which should be the default for most applications anyway. >>> >>> Christos >>> >>> [1] https://reviews.freebsd.org/D49216 > Christos