* data write in alsa
@ 2011-12-02 6:54 Vinod Koul
2011-12-02 7:12 ` Takashi Iwai
0 siblings, 1 reply; 4+ messages in thread
From: Vinod Koul @ 2011-12-02 6:54 UTC (permalink / raw)
To: Takashi Iwai, Mark Brown; +Cc: alsa, Pierre-louis Bossart
Hi Takashi,
For alsa pcm we have two ways to write data, either we use write()
system call or use ioctl SNDRV_PCM_IOCTL_WRITEI_FRAMES.
Is there any specific reason why we have two methods and which one is
preferred and why?
This question is basically for compress API, should we add similar write
method thru ioctls, if so why?
--
~Vinod
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: data write in alsa
2011-12-02 6:54 data write in alsa Vinod Koul
@ 2011-12-02 7:12 ` Takashi Iwai
2011-12-02 7:16 ` Jaroslav Kysela
0 siblings, 1 reply; 4+ messages in thread
From: Takashi Iwai @ 2011-12-02 7:12 UTC (permalink / raw)
To: Vinod Koul; +Cc: alsa, Mark Brown, Pierre-louis Bossart
At Fri, 02 Dec 2011 12:24:41 +0530,
Vinod Koul wrote:
>
> Hi Takashi,
>
> For alsa pcm we have two ways to write data, either we use write()
> system call or use ioctl SNDRV_PCM_IOCTL_WRITEI_FRAMES.
>
> Is there any specific reason why we have two methods and which one is
> preferred and why?
Well, I only remember vaguely. IIRC, ioctl is used since it can pass
the error code more directly without using errno. Maybe Jaroslav
knows more exact reason.
But, honestly speaking, I don't like this implementation. For a new
interface, I'd suggest to stick with the normal read/write. Otherwise
you'll get a mess of 32bit compat layer again.
Takashi
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: data write in alsa
2011-12-02 7:12 ` Takashi Iwai
@ 2011-12-02 7:16 ` Jaroslav Kysela
2011-12-02 11:47 ` Vinod Koul
0 siblings, 1 reply; 4+ messages in thread
From: Jaroslav Kysela @ 2011-12-02 7:16 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Vinod Koul, Mark Brown, alsa, Pierre-louis Bossart
Date 2.12.2011 08:12, Takashi Iwai wrote:
> At Fri, 02 Dec 2011 12:24:41 +0530,
> Vinod Koul wrote:
>>
>> Hi Takashi,
>>
>> For alsa pcm we have two ways to write data, either we use write()
>> system call or use ioctl SNDRV_PCM_IOCTL_WRITEI_FRAMES.
>>
>> Is there any specific reason why we have two methods and which one is
>> preferred and why?
>
> Well, I only remember vaguely. IIRC, ioctl is used since it can pass
> the error code more directly without using errno. Maybe Jaroslav
> knows more exact reason.
The true reason was to avoid the audio frame <-> byte conversions.
> But, honestly speaking, I don't like this implementation. For a new
> interface, I'd suggest to stick with the normal read/write. Otherwise
> you'll get a mess of 32bit compat layer again.
I think that for compressed data, the standard r/w ops are fine, because
there are no "frames".
Jaroslav
--
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: data write in alsa
2011-12-02 7:16 ` Jaroslav Kysela
@ 2011-12-02 11:47 ` Vinod Koul
0 siblings, 0 replies; 4+ messages in thread
From: Vinod Koul @ 2011-12-02 11:47 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Takashi Iwai, alsa, Mark Brown, Pierre-louis Bossart
On Fri, 2011-12-02 at 08:16 +0100, Jaroslav Kysela wrote:
> > But, honestly speaking, I don't like this implementation. For a new
> > interface, I'd suggest to stick with the normal read/write.
> Otherwise
> > you'll get a mess of 32bit compat layer again.
>
> I think that for compressed data, the standard r/w ops are fine,
> because
> there are no "frames".
Thanks, I had the same assumptions as well, wanted to check before
posting next version
--
~Vinod
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-12-02 11:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-02 6:54 data write in alsa Vinod Koul
2011-12-02 7:12 ` Takashi Iwai
2011-12-02 7:16 ` Jaroslav Kysela
2011-12-02 11:47 ` Vinod Koul
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.