Re: [flac-dev] Enabling universal building of libFLAC

[Cristian Adam]

Hi,

Building with CMake for both x86_64 and aarch64 for MacOS is as easy as
setting the CMake configuration
variable: "-DCMAKE_OSX_ARCHITECTURES=x86_64;arm64" when configuring the
project.

See How do I build cmake from source as universal(arm64 and x86_64) binary
on Mac? - Usage - CMake Discourse


for a similar case.

Cheers,
Cristian.


On Sat, Sep 17, 2022 at 5:46 PM Martijn van Beurden 
wrote:

> Hi all,
>
> As is being discussed here: https://github.com/xiph/flac/issues/453
> libFLAC has some issues building on MacOS. More specifically, building for
> aarch64 and x86_64 at the same time.
>
> The problem here is that autotools and CMake expect to configure for one
> architecture at a time. Also, code is dependent on that configuration, and
> not on runtime variables.
>
> It seems a challenge to me: we need both configuration and building to be
> aware of stuff being built in parallel for two architectures. Also, it is
> important not to break anything on other architectures, so we might need
> both approaches: relying on either run-time arch for MacOS and on static
> configuration for other systems.
>
> I do not have Apple hardware nor any experience with this. I can't seem to
> find much documentation on porting autotools or CMake scripts for Apple's
> universal builds. If there is anyone here up for this challenge, do not
> hesitate to let me know :)
>
> Kind regards, Martijn van Beurden
> ___
> flac-dev mailing list
> flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Playing FLAC Files on Audi MMI

[Cristian Adam]

On Wed, May 10, 2017 at 4:45 AM, elio manes 
wrote:

> Hello,
>
>
> I am hoping that perhaps you know the answer to my car audio question, or
> can at least point me in the right direction.  I own a 2013 Audi S4 that
> has the 3G-Plus Multi Media Interface (MMI) with the Bang & Olufsen Sound
> System.
>
>
> The MMI is able to playback lossy, compressed audio files (MP3, WMA and
> AAC), but does not have native support for FLAC, ALAC, or WMA Lossless.
> However, I've read that the MMI system in other 2013 Audi models do have
> native support for playing back lossless FLAC and WAVE files.
>
>
> Is there some type of FLAC decoder “plug-in” that I can download (or save
> on to an SD card) that I can then “flash” onto my car’s MMI software so
> that it could playback FLAC files?
>
>
> As I understand it, the MMI employs programmable processors and runs on a
> Unix-like RTOS (Real Time Operating System) that can be updated using a SD
> card/USB/CD containing the software.  MMI software update menu enables
> import/export settings saved as an AES (Advanced Encryption Standard)
> encrypted zip file.
>
>
> Audio files can be played back on the MMI via various drives: two SD card
> readers, a CD/DVD drive, iPod (MDI), USB, Aux-in, as well as by Bluetooth
> Streaming and WiFi hotspot. However, I would be happy just being able to
> play back FLAC files off the SD card reader!
>
>
>
> I'm a bit of an audiophile and am enjoying the Bang & Olufsen Sound System
> in my S4. It would be a shame to have two SD card slots on the MMI - each
> capable of holding up to 32 GB of music! - and only be able to play off
> them “lossy” audio files.
>
>
> Any thoughts/suggestions that you have would be greatly appreciated.
>
>
>
> Thanks,
>
> Elio
>
>
Hi Elio,

FLAC devs can't do anything about this.

You should talk to Audi. But I wouldn't hold my breath if I were you.
3G-Plus MMI is old and most probably only in maintenance mode.

Audi is using QNX as their "Unix-Line RTOS" OS, which is
proprietary nowdays and developing something for the Audi MMI
is impossible for 3rd parties.

Cheers,
Cristian.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC__BYTES_PER_WORD==8 test results

[Cristian Adam]

On 31-Dec-15 09:00, Erik de Castro Lopo wrote:

Brian Willoughby wrote:


What's wrong with something incredible simple, like:

#define FLAC__BYTES_PER_WORD (sizeof(int))

The fact that it actually is not correct. We want to determine
the size in bits of the CPU registers.

Here's what I know:

   sizeof(int) sizeof (long)
---++-
32 bit Linux   |   4|   4
64 bit Linux   |   4|   8
32 bit windows |   4|   4
64 bit windows |   4|   4

Note that sizeof(long) on 64 bit windows is 4!

Most other unixen follow the LP64 scheme used by Linux.

Erik


On Windows x64 sizeof(long) is 4, but sizeof(ptrdiff_t) is 8.

Any reasons for not using sizeof(ptrdiff_t)?

Cheers,
Cristian.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Updated MSVC patch

[Cristian Adam]

Great.

I need to correct my statement, the check for _MSC_VER <= 1600
was the culprit, like this case:

#if defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__
#include  /* for off_t */
#if _MSC_VER <= 1600 || defined __BORLANDC__ /* @@@ [2G limit] */
#ifndef fseeko
#define fseeko fseek
#ifndef fseeko
#define fseeko fseek
#endif
#endif

Cheers,
Cristian.

On Wed, Mar 6, 2013 at 6:24 PM, Ben Allison  wrote:

> Those checks account for compiler changes/improvements introduced in
> Visual Studio 2010 that are not present in Visual Studio 2008.
>
> I will grab Visual Studio 2012 off of MSDN and make sure everything is OK
> there.
>
> -Ben
>
> > Hi Ben,
> >
> > Can you please remove the _MSC_VER >= 1600 check?
> >
> > _MSC_VER 1600 is set for Visual Studio 2010, which means
> > that Visual Studio 2012 will get a lot of errors because _MSC_VER
> > is defined as 1700.
> >
> > Cheers,
> > Cristian.
> >
> > On Wed, Mar 6, 2013 at 5:53 PM, Ben Allison  wrote:
> >
> >> Thanks, Erik.
> >>
> >> This is the delta that should fix everything up.
> >> I hope that #include "share/compat.h" is acceptable from the
> >> test_streams
> >> binary.  If not, you can probably change it to FLAC/ordinals.h instead
> >>
> >> Also don't forget to commit my earlier VERSION="1.3.0" patch.  You can
> >> add
> >> the "pre1" in a normal text editor without risk.  I didn't include those
> >> changes in the big patch you committed already.
> >> -Ben
> >>
> >> > Ben Allison wrote:
> >> >
> >> >> Erik, et al.
> >> >>
> >> >> This fixes the entire library and does it more cleanly.  It puts most
> >> of
> >> >> the guts into share/compat.h
> >> >
> >> > Thanks Ben.
> >> >
> >> > I applied a slightly tweaked version of the patch. The patch had to be
> >> > tweaked because it broke the Linux build :-). Specifically, the file
> >> > include/FLAC/ordinals.h is a public header file and should not include
> >> > the project internal header "share/compat.h". I also moved some of the
> >> > #ifdef stuff to "share/compat.h".
> >> >
> >> > What is in git now may not build on windows but should be really,
> >> really
> >> > close. I'd appreciate it if you could test it and report the error
> >> > messages. It might take a couple of iterations but we should get it
> >> > working for all the platforms.
> >> >
> >> > Cheers,
> >> > Erik
> >> > --
> >> > --
> >> > Erik de Castro Lopo
> >> > http://www.mega-nerd.com/
> >> > ___
> >> > flac-dev mailing list
> >> > flac-dev@xiph.org
> >> > http://lists.xiph.org/mailman/listinfo/flac-dev
> >> >
> >>
> >> ___
> >> flac-dev mailing list
> >> flac-dev@xiph.org
> >> http://lists.xiph.org/mailman/listinfo/flac-dev
> >>
> >>
> >
>
>
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Updated MSVC patch

[Cristian Adam]

Hi Ben,

Can you please remove the _MSC_VER >= 1600 check?

_MSC_VER 1600 is set for Visual Studio 2010, which means
that Visual Studio 2012 will get a lot of errors because _MSC_VER
is defined as 1700.

Cheers,
Cristian.

On Wed, Mar 6, 2013 at 5:53 PM, Ben Allison  wrote:

> Thanks, Erik.
>
> This is the delta that should fix everything up.
> I hope that #include "share/compat.h" is acceptable from the test_streams
> binary.  If not, you can probably change it to FLAC/ordinals.h instead
>
> Also don't forget to commit my earlier VERSION="1.3.0" patch.  You can add
> the "pre1" in a normal text editor without risk.  I didn't include those
> changes in the big patch you committed already.
> -Ben
>
> > Ben Allison wrote:
> >
> >> Erik, et al.
> >>
> >> This fixes the entire library and does it more cleanly.  It puts most of
> >> the guts into share/compat.h
> >
> > Thanks Ben.
> >
> > I applied a slightly tweaked version of the patch. The patch had to be
> > tweaked because it broke the Linux build :-). Specifically, the file
> > include/FLAC/ordinals.h is a public header file and should not include
> > the project internal header "share/compat.h". I also moved some of the
> > #ifdef stuff to "share/compat.h".
> >
> > What is in git now may not build on windows but should be really, really
> > close. I'd appreciate it if you could test it and report the error
> > messages. It might take a couple of iterations but we should get it
> > working for all the platforms.
> >
> > Cheers,
> > Erik
> > --
> > --
> > Erik de Castro Lopo
> > http://www.mega-nerd.com/
> > ___
> > flac-dev mailing list
> > flac-dev@xiph.org
> > http://lists.xiph.org/mailman/listinfo/flac-dev
> >
>
> ___
> flac-dev mailing list
> flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] 2GB limit patch

[Cristian Adam]

On 3/4/2013 11:26 PM, Martijn van Beurden wrote:
> On 04-03-13 23:19, Erik de Castro Lopo wrote:
>> Link please?
> http://www.hydrogenaudio.org/forums/index.php?showtopic=99757
>
>> Err, thats a link to a post talking about flac's WAV reader being limited
>> to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed.
>> Due to limitations in the way WAV files are specified, no valid WAV file
>> can ever be over 4Gig.
>>
>> Also, the link in that post contains a flac windows binary which is not
>> of much use.
> It seems Case hasn't released any source, but the other posts in the 
> thread state what changes have been made to get to this.
> ___
> flac-dev mailing list
> flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev

This is an older issue reported in 2007:
http://lists.xiph.org/pipermail/flac-dev/2007-September/002423.html

The fix would be to use _ftelli64 instead of ftell with Visual Studio.
http://msdn.microsoft.com/en-us/library/0ys3hc0b%28v=vs.110%29.aspx

Cheers,
Cristian.

___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] flac source code?

[Cristian Adam]

On 05.02.2011 17:43, Sven-Hendrik Haase wrote:
> Hi, since sourceforge cvs hosting is currently down and there is no
> telling when it will return, I wondered if anybody could had a recent
> backup/export of the repo?
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
Hi,

David Schleef has posted this
 (FLAC code
mirror) on planet.xiph.org .

Cheers,
Cristian.
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] FLAC support for Android?

[Cristian Adam]

On Wed, Feb 25, 2009 at 2:23 PM, Brian Willoughby wrote:

> A better suggestion might be to start with libFLAC, optimize as
> needed, and then submit the optimizations back to the FLAC project
> where they will be more widely useful.
>
> But that's just my opinion.
>
> Brian Willoughby
> Sound Consulting
>

I agree. This way the DirectShow filter for Windows Mobile (based on
libFLAC) will
also benefit from those optimizations.

Cheers,
Cristian.
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] [Flac] Ogg Codecs 0.80.15035

[Cristian Adam]

Cristian Adam wrote:

Hi all,

I've made a test release for Ogg DirectShow Codecs.
You can find it here: 
http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15035.exe


The problem is that I get a HEAP Corruption detected at:

void FLAC__bitreader_free(FLAC__BitReader *br)
{
FLAC__ASSERT(0 != br);

if(0 != br->buffer)
free(br->buffer);


The call stack is:

>libFLAC.dll!FLAC__bitreader_free(FLAC__BitReader * 
br=0x035280c0)  Line 348 + 0xe bytesC
 libFLAC.dll!FLAC__stream_decoder_finish(FLAC__StreamDecoder * 
decoder=0x035265f0)  Line 685 + 0xf bytesC
 libFLAC++.dll!FLAC::Decoder::Stream::~Stream()  Line 56 + 0xf 
bytesC++
 
dsfNativeFLACSource.dll!NativeFLACSourceFilter::~NativeFLACSourceFilter()  
Line 83 + 0x4d bytesC++



I've updated the FLAC source code from 1.1.0 to 1.2.1, with an older 
package (oggcodecs_0.73.1936.exe),

but I want to deliver the new FLAC.

Any pointers?
Because the HEAP Corruption was only 8 bytes. So I've thought of giving 
more memory:


FLAC__bool FLAC__bitreader_init(FLAC__BitReader *br, FLAC__CPUInfo cpu, 
FLAC__BitReaderReadCallback rcb, void *cd)

{
   FLAC__ASSERT(0 != br);

   br->words = br->bytes = 0;
   br->consumed_words = br->consumed_bits = 0;
   br->capacity = FLAC__BITREADER_DEFAULT_CAPACITY;
  
   br->buffer = (brword*)malloc(sizeof(brword) * (br->capacity + 2));


I remember seeing things like br->words = 2049 and br->capacity = 2048. 
This hack fixes the crashes,
the updated setup file is here: 
http://www.xiph.org/dshow/uploads/Main/oggcodecs_0.80.15039.exe


Cheers,
Cristian.


___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev