Re: [PATCH - Intervals v2 1/1] interval: Interpret (x x+1] correctly and return x+1

[Takashi Iwai <tiwai@suse.de>]

On Wed, 24 Oct 2018 09:44:01 +0200,
Timo Wischer wrote:
> 
> On 10/24/18 09:06, Takashi Iwai wrote:
> > On Mon, 22 Oct 2018 09:19:28 +0200,
> > Timo Wischer wrote:
> >> On 10/18/18 20:57, Takashi Iwai wrote:
> >>> But how can it be at the first place?  (352 353) is already empty as
> >>> the frames.  The time could be kept in this representation, but the
> >>> frames must be integer.
> >>>
> >>> Which order of calls did it result in so?
> >>>
> >>> We know that some order of calls make the selection impossible like
> >>> the above, especially when both time and bytes/frames are mixed.
> >>
> >> I have used the following ALSA configuration:
> >>
> >> pcm.test_rate {
> >>      type rate
> >>          slave.pcm hw:gmdcard
> >>          slave.rate 48000
> >> }
> > And which driver is gmdcard?
> >
> >
> > Takashi
> 
> 
> The driver is called Generic Machine Driver (unfortunately we have it
> not yet upstreamed) and it is using the Renesas RCar platform driver
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sh/rcar?h=v4.19)
> 
> 
> But it is also reproducible with hw:Loopback with a slightly different
> rules negotiation but the same result at the end:

If it can be reproduced with the loopback driver, it makes easier to
debug.  But you modified something?  Then it has to be clarified at
first; i.e. let others reproduce your problem.  Otherwise we have no
merit to debug it in our side :)


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel