Re: Issues with more than four channels

On Fri, Jun 12, 2020 at 07:29:23PM +0200, Daniel Gibson wrote:
> On 11.06.20 15:29, Alexandre Ratchov wrote:
> > 
> > The start threshold is larger than the buffer size, so
> > playback will never start.
> > 
> > There's a confusion between output and input periods count. The diff
> > below should fix this. Does it?
> > 
> > [...]
> 
> Yes, this works, thank you!
> This also explains why -mplay helps: In line 791
> "if (!(hdl->sio.mode & SIO_REC)) {" sets "irate = orate;" etc, so
> hdl->par.rate would be set to the right value anyway.
> 
> It seems like irate and orate, iperiods and operiods etc always have to be
> the same (on the same device) - is this guaranteed to work, or could it
> happen that some soundcard demands different values for input and output?
> 
> I mean it works for my device so I'm happy, I'm just wondering :)

Any full-device supports common rates and period size, otherwise
full-duplex audio wouldn't work. The most general audio program
pattern is the below pseudo-code:

	prime(data, buffer_size);
	write_samples(data, buffer_size);
	while (1) {
		read_samples(data, period_size);
		process(data, period_size)
		write_samples(data, period_size);
	}

any program does a subset of this pattern (players don't have the
recording part). Implementations may use a poll()-based event loop or
a callback-based API, but they are all equivalent. If playback and
recording rates or periods were not the same, above pattern wouldn't
work; device would be usable only as two independent play-only and
record-only devices.