Bugs item #3587421, was opened at 2012-11-14 23:26
Message generated for change (Comment added) made by uklauer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110706&aid=3587421&group_id=10706

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: verified
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: HPS (hselasky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs in src/oss.c

Initial Comment:
Hi,

First observation:

oss.c: In function 'ossinit':
oss.c:116: warning: dereferencing 'void *' pointer
oss.c:116: error: request for member '_file' in something not a structure or 
union
oss.c:124: warning: dereferencing 'void *' pointer
oss.c:124: error: request for member '_file' in something not a structure or 
union
oss.c:163: warning: dereferencing 'void *' pointer
oss.c:163: error: request for member '_file' in something not a structure or 
union
oss.c:176: warning: dereferencing 'void *' pointer
oss.c:176: error: request for member '_file' in something not a structure or 
union
oss.c:186: warning: dereferencing 'void *' pointer
oss.c:186: error: request for member '_file' in something not a structure or 
union
oss.c:205: warning: dereferencing 'void *' pointer
oss.c:205: error: request for member '_file' in something not a structure or 
union
oss.c:214: warning: dereferencing 'void *' pointer
oss.c:214: error: request for member '_file' in something not a structure or 
union

Fixed by renaming fileno( into sox_fileno( and defining this:

#define sox_fileno(x) fileno((FILE *)(x))

Second observation:

Default audio driver is not OSS.

env AUDIODEVICE=/dev/dsp AUDIODRIVER=oss rec test.wav

Third observation:

GIO syscalls are still used, and the length is 1 byte. You can check this using 
strace or ktrace.

 15260 sox      RET   read 1
 15260 sox      CALL  read(0x3,0x807b2de37,0x1)
 15260 sox      GIO   fd 3 read 1 byte
       0x0000 ff    

Patch needed:

    /* Change to non-buffered I/O */
    setvbuf(ft->fp, NULL, _IONBF, sizeof(char) * file->size);
    return(SOX_SUCCESS);
}

Change to:

    /* Change to non-buffered I/O */
    setvbuf(ft->fp, NULL, _IOFBF, sizeof(char) * file->size);
    return(SOX_SUCCESS);
}

--HPS

----------------------------------------------------------------------

>Comment By: Ulrich Klauer (uklauer)
Date: 2013-01-07 17:10

Message:
Just considered changing unbuffered into fully-buffered in master, but it
turns out Doug rewrote this last March (solving the first issue), and the
change to unbuffered is already gone. As there are not that many problem
reports about this, I don’t think buffering behaviour should be changed
in dot, though.

----------------------------------------------------------------------

Comment By: HPS (hselasky)
Date: 2013-01-04 14:27

Message:
ad 1: I put a fix into the repository (dot branch).

>Thanks.

ad 2: It is right that OSS is not the preferred driver; the order is
coreaudio, pulseaudio, alsa, waveaudio, sndio, oss, sunau, ao. However,
with your AUDIODRIVER setting, it should use OSS. What happens, and what
do
you expect to happen?

>This is fine. No change needed.

ad 3: I assume switching to fully buffered I/O could lead to latency
problems. On the other hand, executing a syscall for each byte also seems
to be a lot of overhead. Does it work well with _IOFBF?

> Yes, it works well with _IOFBF under FreeBSD.

----------------------------------------------------------------------

Comment By: Ulrich Klauer (uklauer)
Date: 2013-01-04 14:08

Message:
OK, I don’t have OSS, but let’s see …

ad 1: I put a fix into the repository (dot branch).

ad 2: It is right that OSS is not the preferred driver; the order is
coreaudio, pulseaudio, alsa, waveaudio, sndio, oss, sunau, ao. However,
with your AUDIODRIVER setting, it should use OSS. What happens, and what do
you expect to happen?

ad 3: I assume switching to fully buffered I/O could lead to latency
problems. On the other hand, executing a syscall for each byte also seems
to be a lot of overhead. Does it work well with _IOFBF?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110706&aid=3587421&group_id=10706

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

Reply via email to