Re: [PATCH 2/2] ALSA: usb-audio: Generic application of implicit fb to Roland/BOSS devices

From: Takashi Iwai <tiwai@suse.de>
To: Lucas <jaffa225man@gmail.com>
Cc: alsa-devel@alsa-project.org,
	"Keith A . Milner" <maillist@superlative.org>,
	Mike Oliphant <oliphant@nostatic.org>
Subject: Re: [PATCH 2/2] ALSA: usb-audio: Generic application of implicit fb to Roland/BOSS devices
Date: Fri, 23 Apr 2021 09:47:19 +0200	[thread overview]
Message-ID: <s5hlf99788o.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAOsVg8rAkwLgLP_LSj6CfYG+1R2oB5-sV4KQhLJMqCEqL2wDQA@mail.gmail.com>

On Fri, 23 Apr 2021 08:49:22 +0200,
Lucas wrote:
> 
> Most everything seems to be working, but I ran into a couple of, hopefully,
> simple issues:
> 
> 1. The UA-101 in its full speed (USB 1.1) mode times out for both capture and
> playback, though its high speed (USB 2) mode is perfect.
> (I'm using plughw to work with 2 channels here):
> arecord -D plughw:UA101 -f S32_LE -r 48000 -c 2 ./file.wav
> arecord: main:830: audio open error: Connection timed out
> 
> aplay -D plughw:UA101 -f S32_LE -r 48000 -c 2 ./other-file.wav
> aplay: main:830: audio open error: Connection timed out

Is this really with snd-usb-audio driver?  Please check the entry in
/proc/asound/modules (or traverse via sysfs).

> 2.  I noticed with the INTEGRA-7 and the R-26, so far (with "pasuspender --
> cat" running simultaneously):
> When I first begin playback with aplay like,
> "aplay -D hw:INTEGRA7 -f S32_LE -r 96000 -c 2 ./file.wav"
> to play a long recording, and then start capturing for a while, while that's
> still playing with something like,
> "arecord -D hw:INTEGRA7 -f S32_LE -r 96000 -c 2 ./duplex-file.wav".
> If I then end the arecord with ctrl-c before the aplay has finished, aplay may
> end in the near future without finishing the entire playback, with this:
> aplay: pcm_write:2061: write error: Input/output error
> 
> I may try beginning the capture first, and then starting aplay, but I've run
> out of time for tonight.
> 
> If problem two can't be fixed, this functionality is certainly better than
> before when it wasn't working at all.  I think JACK would keep the capture and
> playback endpoints open, until itself closes, so it's probably a rare person
> like me that would even notice it.

This rather sounds like a generic problem of the implicit feedback.
Please give the kernel log with snd_usb_audio.dyndbg=+p boot option
with some notion which timestamp corresponding to which action
(e.g. starting playback, stopping recording, etc).

thanks,

Takashi