Well, I updated the player to work with the branch_postbeta2, but it contains some nasty kludges to the project files that probably shouldn't be finalized. I'm going to put it in a separate file (http://oscar.the-rileys.net/programming/vorbis_pb2.tar.gz) for now. Unfortunately, this release doesn't seem to fix the "tearing sound" problem. I think this might be related to problems using low-level Ogg Vorbis code as opposed to VorbisFile, but we don't have VorbisFile on Mac yet (I can't see it working very well with Mac HFS functions until Codewarrior gets fdopen() support). The reason I think this is that on linux, the targets that use VorbisFile (ogg123, xmms plugin) do not clip (at least not with the tearing sound associated with the Mac player), while the decoder_example (which uses lower-level functions) reports clipping (though I have yet to test the sound output). It would be nice if we could get VorbisFile working well on the mac, but it requires the use of fopen() streams, and fopen() does not work well with standard Mac file selection (I can get a fd, but there's no fdopen() support in Codewarrior for the mac, though there is on the BeOS side(!)). Anyway, I'd love help from anyone who has tried the sound output from the decoder_example on, say, Linux (or even mac... anyone know a PCM player?) and can report whether there is nasty ripping sounds when it clips. The odd side effect to the clipping (which would otherwise be a minor annyance) is that it seems to take up extra samples (the sound playback slows when there is lots of it). Can anyone venture a guess as to why this is? --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
David Riley wrote:> > Anyway, I'd love help from anyone who has tried the sound output from > the decoder_example on, say, Linux (or even mac... anyone know a PCM > player?) and can report whether there is nasty ripping sounds when it > clips. The odd side effect to the clipping (which would otherwise be a > minor annyance) is that it seems to take up extra samples (the sound > playback slows when there is lots of it). Can anyone venture a guess as > to why this is?Hmph. decoder_example output sounds fine on Linux, so it seems to be a mac-specific thing. I know the problem is not with Sound Manager, because I get the same noise even if I have a maximum volume of 255 (pcm[i][j] * 255.0) and it's the same whether I use assembly or C to convert from float to short. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Anyway, I'd love help from anyone who has tried the sound output from > the decoder_example on, say, Linux (or even mac... anyone know a PCM > player?) and can report whether there is nasty ripping sounds when it > clips. The odd side effect to the clipping (which would otherwise be a > minor annyance) is that it seems to take up extra samples (the sound > playback slows when there is lots of it). Can anyone venture a guess as > to why this is?Hmm.. Maybe you already checked this, but are you getting the samples in the right byte order? --- Stan Seibert --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 10:03 PM -0400 10/10/00, David Riley wrote:>Unfortunately, this release doesn't seem to fix the "tearing sound" >problem.If you're using Standard C I/O functions on the Macintosh, make sure you're using binary mode. (I.e. you're doing fopen(foo, "rb") instead of fopen(foo, "r").) Otherwise, the Metrowerks standard I/O library will "help" you and will convert all newlines to linefeeds and vice versa. You can also link with the (NL) libraries, in which case fopen(foo, "r") will do the Right Thing. -- Chris -- Christopher M. Hanson President & CEO bDistributed.com, Inc. cmh@bDistributed.com --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Dear David Riley,>See, here's the problem. I use StandardGetFile, which returns a reply >that I can really only use to get a file descriptor. It doesn't return >a pathname, though it returns volume ID's and such that I can use for >the standard Mac file routines. If Codewarrior had fdopen(), this would >be great, but for now I'm using the equivalent of open(). Will that not >work? It plays the sound well enough when it doesn't clip. Also, is >there any Mac Toolbox equivalent to fopen() that I could use with an >FSSpec instead of a pathname?Metrowerks' MSL has a function called FSp_fopen -- it's available in a file with same name (+.c/.h) inside MSL C library. It does exactly the same as fopen but accepts FSSpec instead of char* with file path, so you'll be able to open what StdGetFile returns you. =) Sincerely, Slava Karpenko Unsanity, LLC Email: slava@unsanity.com Phone: +7812 9360841 [Russia] Fax: +7812 3070918 [Russia] WWW: http://www.unsanity.com/ --- Unsanity - Unsane tools for insane people --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.