[gstreamer-bugs] [Bug 349015] [sunaudio] open source with O_NONBLOCK

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=349015
 GStreamer | gst-plugins-good | Ver: HEAD CVS


Tim-Philipp Müller changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #70617|none                        |commented-on
               Flag|                            |
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |
   Target Milestone|0.10.4                      |NONE




------- Comment #4 from Tim-Philipp Müller  2006-08-10 09:24 UTC -------
>From the audio man page on Solaris 9:

     When a process cannot open /dev/audio because the device  is
     busy:

        o  if either the O_NDELAY or O_NONBLOCK flags are set  in
           the  open()  oflag  argument,  then  -1 is immediately
           returned, with errno set to EBUSY.

        o  if neither the O_NDELAY nor the  O_NONBLOCK  flag  are
           set,  then  open() hangs until the device is available
           or a signal is delivered to the process, in which case
           a -1 is returned with errno set to EINTR.  This allows
           a process to block in the open call while waiting  for
           the audio device to become available.

As Jan already said, the purpose of the NONBLOCK parameter was to avoid hanging
in open if opening the device is not possible right away.


Also

  Recording Audio Data
     The read() system call copies data from the system's buffers
     to the application. Ordinarily, read() blocks until the user
     buffer is filled. The I_NREAD ioctl (see  streamio(7I))  may
     be  used  to  determine  the amount of data that may be read
     without blocking.  The device may alternatively be set to  a
     non-blocking  mode,  in  which case read() completes immedi-
     ately, but may return fewer bytes than requested.  Refer  to
     the  read(2)  manual page for a complete description of this
     behavior.

only says that in non-blocking mode read() may return fewer bytes than
requested, which doesn't mean data is lost, does it? (this is standard
behaviour for read() in non-blocking mode for all devices as far as I know).

But maybe we should just set the fd back to non-blocking again with fcntl()
after opening it successfully?


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.