On 12-10-20, 09:01, Takashi Iwai wrote: > On Mon, 12 Oct 2020 07:25:25 +0200, > > So what if we add another state but keep it in kernel (hidden from > > userspace)...? > > That's fine, then it's just a kernel's business, and it should be > determined which one makes the code better. > > But, there are things to be considered, though: > > - SNDRV_PCM_STATE_* is defined as snd_pcm_state_t with __bitwise. > This indicates that the type has to be defined in that way > explicitly. > > - Having a value over SNDRV_PCM_STATE_LAST internally is hackish. > > > Right now tinycompress does not make use of PCM streams, kernel handles > > these. I am not aware of any other implementation. > > > > So if the scope if within compress then it might work... > > Yes. But currently the API uses SND_PCM_* even for the compress > stuff. Changing this value means to have influence on PCM, even if > PCM stuff doesn't use it yet. (At least you'd need to increase > SND_PCM_STATE_LAST, for example.) > > That said, if we want to change only for compress API by assuming that > the impact must be negligible, the first step would be to move from > SND_PCM_STATE_* to the own state, SND_COMPRESS_STATE_*. The values > should be compatible, but this has to be changed at first. Then you > can introduce a new value there. I think that sounds reasonable to me, we should not have used SNDRV_PCM_STATE_* in the first place and long term fix for this should be SNDRV_COMPRESS_STATE_ I will cook a patch for this Thanks -- ~Vinod
