Re: [Gap-dev-discuss] Cynthiune: song inspector without title bar

[Sebastian Reitenbach]

On Saturday, May 5, 2012 14:16 CEST, "Sebastian Reitenbach" <address@hidden> 
wrote:

>
> On Saturday, May 5, 2012 13:53 CEST, Philippe Roussel <address@hidden> wrote:
>
> > Le 05/05/2012 13:02, Sebastian Reitenbach a écrit :
> > >
> > > On Saturday, May 5, 2012 12:05 CEST, "Sebastian Reitenbach" 
> > > <address@hidden> wrote:
> > >
> > >>
> > >> On Friday, May 4, 2012 14:32 CEST, Riccardo Mottola <address@hidden> 
> > >> wrote:
> > >>
> > >>> On 05/04/12 12:08, Sebastian Reitenbach wrote:
> > >>>>
> > >>>> On Friday, May 4, 2012 11:55 CEST, Riccardo Mottola<address@hidden>  
> > >>>> wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> On 05/03/12 12:38, Andreas Schik wrote:
> > >>>>>> Hi,
> > >>>>>> I am using Cynthiune on Linux (Ubuntu 10.04) w/o major problems so 
> > >>>>>> far.
> > >>>>>> Even the new ALSW backend worked w/o any hassle :-) Thanks.

> > >>>>>> The only issue I have so far is with the song inspector. It comes
> > >>>>>> completely w/o window decorations. I observed this on xfce and GNOME,
> > >>>>>> while on WindowMaker the title bar was there. After digging for a 
> > >>>>>> while,
> > >>>>>> I found that the gorm bundle does not set the NSTitledWindowMask flag
> > >>>>>> for the panel. I don't know why, though. I also don't know about the 
> > >>>>>> nib
> > >>>>>> bundle. Is there any way to fix that w/o having to recreate the gorm 
> > >>>>>> bundle?
> > >>>>> The window should be fine.
> > >>>>>
> > >>>>> I tried the Alsa backend on debian/linux/ppc on my iBook and I just 
> > >>>>> get
> > >>>>> garbage-sounding output when I play files. (mpg123 works...). I didn't
> > >>>>> try OSS because I have a minimal install and don't have the OSS> 
> > >>>>> >>>>> compatibilty layer...
> > >>>>> On my x86 though it works.
> > >>>> IIRC, PowerPC is big endian, and there may be more a problem in the 
> > >>>> MP3 decoder
> > >>>> than with the output plugin? But I'm just guessing. I can probably try 
> > >>>> on the weekend
> > >>>> or maybe even later today, on my OpenBSD macppc notebook.
> > >>>>
> > >>> Ok, do some tests.. although this is linux here. PPC is big endian on
> > >>> macs. I also have a sparc machine, but it is slow and has no sound 
> > >>> output.
> > >>
> > >> OK, I can confirm the garbage noise on OpenBSD macppc. I tried with 
> > >> AO/Esound/Sndio backend, all the
> > >> same. Also tried MP3 and FLAC files, all the same noise. So also for me, 
> > >> mpg321 works
> > >> well, and the sound is way much better than on my intel based notebook 
> > >> ;).
> > >> So the problem doesn't seem to depend on the backend, nor the input 
> > >> format,
> > >> seems to be more general as it seems.
> > >>
> > >> Needs more investigation.
> > >
> > > I was able to fix the problem for the Sndio Output Bundle. I remembered 
> > > the manual page:
> > >
> > > http://www.openbsd.org/cgi-bin/man.cgi?query=sio_open&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
> > >
> > > The struct sio_par has a parameter le, which defines the Endianess. 
> > > Setting this
> > > parameter to LE, makes the sound work again for me on i386 and on macppc.
> > >
> > > A patch would look liek this:
> > >
> > > Index: Sndio.m
> > > ===================================================================
> > > RCS file: /sources/gap/gap/user-apps/Cynthiune/Bundles/Sndio/Sndio.m,v
> > > retrieving revision 1.2
> > > diff -u -r1.2 Sndio.m
> > > --- Sndio.m       1 May 2012 12:44:46 -0000       1.2
> > > +++ Sndio.m       5 May 2012 11:01:00 -0000
> > > @@ -108,6 +108,7 @@
> > >    sio_initpar(&par);
> > >    par.pchan = numberOfChannels;
> > >    par.rate = sampleRate;
> > > +  par.le = 1;
> > >
> > >    if (sio_setpar(hdl, &par))
> > >      {
> > >
> > >
> > > Don't know whether other output libraries have the same functionality
> > > to force it to little endian.
> >
> > For AO you can try to modify format.byte_format with one of the
> > following flags :
> >
> >     AO_FMT_LITTLE - Samples are in little-endian order.
> >     AO_FMT_BIG - Samples are in big-endian order.
> >     AO_FMT_NATIVE - Samples are in the native ordering of the computer.
>
> Yeah, I already found that. Changing it to AO_FMT_LITTLE made it work
> on macppc too. However, there is another problem.
> When it automatically jumps from a 44100Hz to a 160000Hz bitrate file, or
> vice-versa, Cynthiune crashes on macppc (not on i386). I use the new ao.m
> file you sent, which closes and reopens the device. The backtrace looks like 
> this:
>
> (gdb) bt
> #0  0x860afec8 in ao_plugin_close ()
>    from /usr/local/lib/ao/plugins-4/libsndio.so
> #1  0x85ebb704 in ao_close () from /usr/local/lib/libao.so.5.0
> #2  0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #3  0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #4  0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #5  0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #6  0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #7  0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #8  0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #9  0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #10 0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #11 0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> ---Type <return> to continue, or q <return> to quit---
> #12 0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #13 0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #14 0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #15 0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #16 0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> #17 0x85e51d78 in -[AO prepareDeviceWithChannels:andRate:] (self=0x852bd008,
>     _cmd=Variable "_cmd" is not available.
> ) at ao.m:95
> ...
> the same here up to the last stack frame which is #27.
>
>
> But this may be a problem in libao, I need to compile it with debug symbols.

OK, patching two NULL pointer dereferences in libao's sndio output plugin away, 
I now
get this crasher with AO output bundle on macppc: Something is freed which is 
already
freed before :(
The problem doesn't show up on i386.

 $ cat crasher2                                                        
Thread 1 (thread 1005286):
#0  0x820e98e8 in kill () from /usr/lib/libc.so.64.0
#1  0x82158ca4 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2  0x821564bc in wrterror (msg=Variable "msg" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:269
#3  0x82157ad8 in free (ptr=0x8ad6c180)
    at /usr/src/lib/libc/stdlib/malloc.c:1240
#4  0x863d1af8 in default_free (zone=0x865de328, ptr=0x8ad6c180)

    at NSZone.m:158
#5  0x863d5924 in NSZoneFree (zone=0x865de328, ptr=0x8ad6c180) at NSZone.m:2149
#6  0x862dd7f8 in NSDeallocateObject (anObject=0x8ad6c188) at NSObject.m:881
#7  0x862de270 in -[NSObject dealloc] (self=0x8ad6c188, _cmd=0x865ad4d4)
    at NSObject.m:1419
#8  0x862dff00 in -[NSObject release] (self=0x8ad6c188, _cmd=0x8657db10)
    at NSObject.m:2058
#9  0x861c7bf4 in -[NSAutoreleasePool emptyPool] (self=0x8accb008,
    _cmd=0x865bc624) at NSAutoreleasePool.m:656
#10 0x863319e0 in -[NSRunLoop(Private) _checkPerformers:] (self=0x88e0f8c8,
    _cmd=0x865bc73c, context=0x88e17608) at NSRunLoop.m:482
#11 0x86334be8 in -[NSRunLoop acceptInputForMode:beforeDate:] (
    self=0x88e0f8c8, _cmd=0x865bc77c, mode=0x865bbf94, limit_date=0x82f3ca88)
    at NSRunLoop.m:1199
#12 0x86335068 in -[NSRunLoop runMode:beforeDate:] (self=0x88e0f8c8, 
---Type <return> to continue, or q <return> to quit---
    _cmd=0x81f56518, mode=0x865bbf94, date=0x89d4f148) at NSRunLoop.m:1263
#13 0x81db5024 in -[GSDisplayServer(EventOps) 
getEventMatchingMask:beforeDate:inMode:dequeue:] (self=0x88dc0a08, 
_cmd=0x88ee1184, mask=4294967295,
    limit=0x89d4f148, mode=0x865bbf94, flag=1 '\001') at GSDisplayServer.m:1035
#14 0x88e7d5bc in -[XGServer(X11Ops) 
getEventMatchingMask:beforeDate:inMode:dequeue:] (self=0x88dc0a08, 
_cmd=0x81ea6f98, mask=4294967295, limit=0x89d4f148,
    mode=0x865bbf94, flag=1 '\001') at XGServerEvent.m:2557
#15 0x81b109d4 in DPSGetEvent (ctxt=0x88dc0a08, mask=4294967295,
    limit=0x89d4f148, mode=0x865bbf94) at GSDisplayServer.h:198
#16 0x81b11940 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] (self=0x88dbd688, 
_cmd=0x81ea7208, mask=4294967295, expiration=0x89d4f148,
    mode=0x865bbf94, flag=1 '\001') at NSApplication.m:2161
#17 0x81b0f4f0 in -[NSApplication run] (self=0x88dbd688, _cmd=0x81e9cf38)
    at NSApplication.m:1552
#18 0x81ae1e20 in NSApplicationMain (argc=1, argv=0xffff4c64) at Functions.m:91
#19 0x01802b40 in gnustep_base_user_main (argc=1, argv=0xffff4c64) at main.m:27
#20 0x86316720 in main (argc=1, argv=0xffff4c64, env=0xffff4c6c)

    at NSProcessInfo.m:989
#21 0x01802924 in ___start ()
#22 0x00000000 in ?? ()




>
> Sebastian
>
> >
> > Philippe
> >
>
>
>
>
>